Getting some strange errors on deployment

[lostpebble]

I 2020-05-26T13:40:22.579388309Z   <-- POST /_wildcard_api/updateLockdownRule/args-in-body
E 2020-05-26T13:40:22.582009313Z 
E 2020-05-26T13:40:22.582077999Z Malformatted API request `/_wildcard_api/updateLockdownRule/args-in-body`.
E 2020-05-26T13:40:22.582085676Z Cannot JSON parse `[{"rule":{"_key":"q2dY","_id":"covid_lockdown_rules/q2dY","_rev":"_ajC0PfS--B","name":"Events","icon":"ZDz4","customRuleDetails":[],"levelDetails":[{"lvl":1,"type":"NOT_ALLOWED","customValues":[]},{"lvl":2,"type":"NOT_ALLOWED","customValues":[]},{"lvl":3,"type":"NOT_ALLOWED","customValues":[]},{"lvl":4,"type":"NOT_ALLOWED","customValues":[]},{"lvl":5,"type":"NOT_ALLOWED","customValues":[]}],"categories":["ZBlt","PgU-"],"description":"Sporting or Entertainment","dateCreated":"json-s:tYpE|Date|2020-05-26T13:35:34.303Z"}}]`.
E 2020-05-26T13:40:22.582097456Z JSON Parse Error:
E 2020-05-26T13:40:22.582102226Z assert.internal is not a function
E 2020-05-26T13:40:22.582107151Z
E 2020-05-26T13:40:22.582107151Z 
I 2020-05-26T13:40:22.582910504Z   --> POST /_wildcard_api/updateLockdownRule/args-in-body 400 4ms 673b

Hi Romuald, hope you're well :)

Just started getting some strange errors on a new deployment today. The strange thing is that these errors only started occurring after some time - and now even with a renewed deployment, they are still occurring. Its all very weird.

I'm investigating now, but just thought I'd drop this here in case you've ever seen something like this happening with Wildcard before. It seems that assert.internal is failing, so could have something to do with your custom assert library, perhaps not installing properly on the deployment side... but it should be.

[lostpebble]

I see you recently updated https://github.com/brillout/assert

So I'm thinking it could have something to do with a version mismatch, because yarn could be installing a different version on the deployment build side. I should throw my yarn.lock file in there as well to prevent such things...

[brillout]

Hi Paul, I'm looking at it right now. Yes it's most likely due to changes I did to @brillout/assert.

[brillout]

I'm suspecting cycling dependency to be the cause. Does pinning @brillout/assert to 0.1.6 fix the issue?

[brillout]

To temporarily pin you can yarn add @brillout/assert@0.1.6 then manually replace the 0.1.7 version with the code of the 0.1.6 version in node_modules/.

I'm currently trying to reproduce this on my side.

[lostpebble]

Cool, I'll try that now.

These errors are only happening on my deployment, so I'll need to re-deploy to check.

[brillout]

I currently still can't reproduce this.

All Wildcard tests are passing with the latest @brillout/assert version 0.1.7.

I'm further digging how to reproduce this.

I'll try that now.

Ok great, it could reduce the error search space to only couple of lines of changes.

[brillout]

70% chance that I will publish a fix within the next 10 minutes.

[lostpebble]

Ahhh... I think I may know what is causing the issue. And this is a big lesson perhaps about using yarn.lock for your cloud deployment builds...

Since my code is built in two places, I have the frontend bundle.js which is obviously pre-built with webpack on my dev side, and then the server code server.js which just expects the node modules to be installed when it runs.

The mismatch probably came in the wildcard dependencies which were bundled with webpack on my dev environment, and therefor in the final deployment they were different on the client-side to the now newer modules being used on the server side.

Does this sound plausible?

Almost up with the new deployment.

[brillout]

I could reproduce.

98% change that I will publish a fix within 5 minutes :-)

[lostpebble]

Loving the live publishing stats! haha

Cool, I'm updating my deployment. It hasn't hardcoded any version, but my bundle.js has been built with the 0.1.7 version.. just to check. If that doesn't work then I'll add a hardcode of the version - or just wait for you fix which will actually come sooner.

[brillout]

rm yarn.lock && yarn should fix this

[lostpebble]

Yea, but that will also destroy all my other dependencies and their version targets. Its a very large yarn.lock file and I don't like to mess with it too much since I've run into headaches a lot before with version stuff.

[brillout]

Ok then upgrade @brillout/json-s to ^0.1.1. AFAIK you can simply change the yarn.lock line that tells what @brillout/json-s version is being used.

I'm also going to bump the wildcard-api version in a moment, if it's more convenient for you. I'll publish it after I finished writing the new unit test.

[lostpebble]

Glad to report that after uploading my yarn.lock file alongside my deployment files, it is now working without issue.

There was never an issue with my yarn.lock file btw, as I couldn't reproduce the error in my development environment - so it was working as intended and installing older parts of the wildcard dependencies which didn't have any issues. Now that I've deployed my local yarn.lock file alongside my package.json, I'm getting the correct old versions installed.

[brillout]

Going to eat something, I'm starving haha. I'll update Wildcard later tonight.

[brillout]

Done.

Upgrading to the newly published Wildcard version yarn add @wildcard-api/client@0.3.1 && yarn add @wildcard-api/server@0.3.1 will fix the problem.

I added an automated test to ensure this doesn't happen again.

Btw. I'll be in Paris for couple of days in July :)

[lostpebble]

Great, thanks!

Cool, shoot me a message closer to the time and lets make a plan to grab a beer :)