Freecodecamp: Potential issue with dev sign in

[ojeytonwilliams]

@RandellDawson and @ahmadabdolsaheb found themselves unable to log in locally. Ahmad's issue was fixed by npm run seed, but Randy's was not. Could you explain a bit in this issue if the problem persists?

It might be nothing, but it could be a sign something isn't quite right.

[Sky020]

I am able to log in, and save settings. I did however get a bunch of errors on the landing page, which I resolved by adding:

ALGOLIA_ADMIN_KEY=123abc
ALGOLIA_APP_ID=X5V7KWJ4RB
ALGOLIA_API_KEY=a45d2b80c97479bbda5cf5c55914230f

Back to .env

Possibly useful to take a look at what changes #39443 made, and correct the setup for the changes.

[Sky020]

Here are the errors I am getting without the above _env_ vars

Slightly more verbose:

[raisedadead]

Thanks for confirming, we should add some defaulting logic to this actually in dev mode.

Speaking of which @scissorsneedfoodtoo do you know if we have a test instance of Algolia, I do not see any on the dashboard.

[RandellDawson]

The only way I was able to finally clear up the errors I was seeing, was to clear my cache for localhost. Before that, I had tried:

1. resyncing master
2. running the following commands:

cp sample.env .env
npm run clean
npm ci
npm run seed
npm run develop

I was not able to just do a hard refresh of the page (Ctrl + F5). I literally had to go into browser history and delete out localhost history.

Before clearing my cache, I was getting the "Something is not quite right. A report has been generated and the freeCodeCamp.org team have been notified." message and seeing the following in the terminal when the main home page loaded.

[raisedadead]

Thanks @RandellDawson this additional information helps. The secrets were changed (by me) on the sample.env which have led the sessions (in the local db on your end) to go stale.

The client is sending the session details to the API, the API is also correctly seeing them in the db, but because the key (which encrypted) the tokens in the first place has changed it is erroring out.

This is kind of expected. The fix is to purge the cache on the browser (techically you need to purge the db, where the keys are, but clearing the cache should be enough).

[RandellDawson]

techically you need to purge the db, where the keys are, but clearing the cache should be enough

Wouldn't the npm run seed have purged the db?

[raisedadead]

Nope. It will only "seed" the user collection if it is not present already. It would not create/remove anything else by design.

[RandellDawson]

Should we add something to npm run seed that purges the local db and then seeds it?

[raisedadead]

It would not create/remove anything else by design.

Like I said, this behaviour is intentional. The DB is not a ephemeral entity. It should not be mutated after intial setup. That is the only way you would catch potential bugs from reaching production.

The DX is not the end goal, the production is.

[ojeytonwilliams]

Oh, so because I don't keep my browser cache, it kept requesting a new token?

[raisedadead]

Oh, so because I don't keep my browser cache, it kept requesting a new token?

Yes.

[scissorsneedfoodtoo]

@raisedadead, we do have a test instance of Algolia, but I accidentally created it under my account rather than a general team account, so only I have access to it.

I'll create a test instance under the team account and create a PR to update the keys in sample.env.

[raisedadead]

I am not in favor of adding our keys (although these are client side keys for algolia) to version control. Instead the search feature sould be mocked/disabled in developement.

[scissorsneedfoodtoo]

@raisedadead, sure, that sounds good. I think it'll throw errors for now, but there's probably a good way to disable search altogether in development.

[Twaha-Rahman]

Let's mock the search feature. We can test then.

What do you guys say?

[scissorsneedfoodtoo]

Hey @Twaha-Rahman, thank you for all of your help with testing. It's been awesome to see how quickly the test coverage has improved with each of your PRs.

I'm all for mocking the search bar. Now that Cypress is in place, it will be good to make sure things like the up and down keys and mouse entering / leaving the dropdown is working as expected. I haven't looked much into it, but it should be possible to pass a mock Algolia response to the SearchHits component somehow.