Change:
and found themselves unable to log in locally. Ahmad's issue was fixed by , 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.
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: Back to Possibly useful to take a look at what changes made, and correct the setup for the changes.
Here are the errors I am getting without the above env vars ! Slightly more verbose: !
Thanks for confirming, we should add some defaulting logic to this actually in dev mode. Speaking of which do you know if we have a test instance of Algolia, I do not see any on the dashboard.
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: master the following commands: 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 team have been notified." message and seeing the following in the terminal when the main home page loaded. !
Thanks this additional information helps. The secrets were changed (by me) on the 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).
Wouldn't the have purged the db?
Nope. It will only "seed" the user collection if it is not present already. It would not create/remove anything else by design.
Should we add something to that purges the local db and then seeds it?
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.
Oh, so because I don't keep my browser cache, it kept requesting a new token?
Yes.
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
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.
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.
Let's mock the search feature. We can test then. What do you guys say?
Hey 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 component somehow.

Discussion:
const searchClient = algoliaAppId && algoliaAPIKey ? algoliasearch(algoliaAppId, algoliaAPIKey) <del> : {}; </del> <ins> : { search: () => {} }; </ins> const propTypes = { children: PropTypes.any,

key={hit.objectID} > {noHits ? ( <del> <NoHitsSuggestion title={noHitsTitle} /> </del> <ins> <NoHitsSuggestion handleMouseEnter={handleMouseEnter} handleMouseLeave={handleMouseLeave} title={noHitsTitle} /> </ins> ) : ( <Suggestion handleMouseEnter={handleMouseEnter}