"Data argument must be of type"..."Received null" error during restore process
-
I have seen a very strange error when restoring Cloudron on a new server...
The "data" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received null
Any ideas what this could be referring to? It counts up all the downloaded files as it downloads from Vultr Object Storage and I see the disk space continue growing from it's default size to about 45 GB, then it sort of fails with the error above. I've run into this twice now and not sure why this is failing.
-
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.
-
@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?
-
@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 I sent you a mail from support@cloudron.io , let's continue there.
-
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 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.
-
@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.