"Data argument must be of type"..."Received null" error during restore process

[robi]

@d19dotca best to email support and give them a way to access the server in this case.

[d19dotca]

Agreed. Sent email a few moments ago, @girish Any help would be greatly appreciated.

[d19dotca]

Just a quick update: they’re stilling working on it, seems like a bug at initial review. So may take some time to sort out.

[girish]

The code went through quite a rewrite in the next release. Do you think you can hold off on the migration till 6.4? I don't have an ETA for 6.4 but we are just writing the features and I expect this week and the next to be busy with that.

[d19dotca]

@girish I can, though I was hoping not to as at the end of the month I will be charged for all of October (it's part of why OVH is so cheap, you pay for the month in advance, hourly pricing is double the price in the end). I can just try to schedule this for later in October though with the hopes that 6.4 will be out by then. Though I'm a bit concerned that from the email 6.4 may not resolve the issue either it's just assumed it might given the massive rewrite. How confident are you that it'd be fixed for 6.4? And do you expect it out by like mid-late October approximately by any chance?

[girish]

@d19dotca Do you still have that server around or alternately can you help me reproduce this? If so, can you mail us at support@cloudron.io and I can take a look. Somehow I suspect this won't be automagically fixed by the code refactor, so worthwhile taking a look.

[d19dotca]

@girish I don't have the destination server but I of course still have my prod server I was trying to migrate from. My server still has SSH access for support enabled if you want to access it at all.

[girish]

@d19dotca I sent you a mail from support@cloudron.io , let's continue there.

[girish]

Thanks for the access @d19dotca . There are multiple problems:

• The error handling code in https://git.cloudron.io/cloudron/box/-/blob/7913b8e862c19cd1af0074abf42da803f3c6d44a/src/reverseproxy.js is wrong. The return callback() in line 252 is being called inside forEach.

• The reason why others have not hit this is because that code path should ideally never be hit. The root cause seems to be that fallback certificates for many of the domains are missing. I am not sure how/why but looks like some old migration code failed. Fallback certs are just the self-signed certs that we generate per domain in case Let's Encrypt fails. So, it's easy to just generate new ones.

I will make the code changes for the next release.

[girish]

Fixed with https://git.cloudron.io/cloudron/box/-/commit/b642bc98a5e2f2d3ef64e9a2b9b79d7a1ddac500

[d19dotca]

@girish thank you so much for looking into this! Will the fix regenerate the self-signed fallback certs or will I need to make some manual changes?

[girish]

@d19dotca yes, it will re-generate the certs. no need for any manual intervention.

[d19dotca]

@girish out of curiosity, in the event I wanted to try my migration this weekend (I will likely wait for next weekend if 6.4 is out in time), is there a manual way for me to circumvent this issue by regenerating the self-signed certs or something? If it’s far too complicated then no worries, I’m just getting a little anxious having only really two weekends left to make the migration happen excluding this weekend since 6.4 isn’t quite ready yet. Wanted to try and form a backup plan just in case.

[girish]

@d19dotca yeah, it requires a database migration, so it's a bit complicated to do this manually. It's this one - https://git.cloudron.io/cloudron/box/-/commit/b642bc98a5e2f2d3ef64e9a2b9b79d7a1ddac500 . I would say, in the case that we are unable to release the new version next week, I will make a script out of that code that will fix it.

[d19dotca]

@girish That'd be awesome, thanks Girish. I'll hope it's ready for this week though for everyone and that should fix it.