Hi Alan, yes, I have the shop, timestamp and HMAC of the request. How do I send you a DM?
Thanks @flavio-b, at the moment only staff can open up DMs with āregularā forum users, Iāll DM you right away here so we can work on this together more closely. Speak to you in the DM there in just a moment!
1 Like
Hi @Alan_G thank you for the support and technical advise. Looks like it worked for my issue.
Yes, weāve seen this too after moving to the CDN version of App Bridge. Itās not super frequent, but every so often a request will come through with an undefined JWT, and it seems to line up with redirects or certain admin actions. Like you, we never noticed it back on 4.x.x.
From what weāve tested, it doesnāt look like something we can fully control app-side ā more like a timing/initialization issue with App Bridge or how the token is being passed during redirects. We ended up adding some defensive checks and retries on our end so that if a request comes through without a token, it tries again before failing. Thatās reduced the noise a lot, but obviously itās not a real fix.
Would definitely be interested if anyone has found a more solid workaround or if Shopify has acknowledged this as a bug.
@Alan_G has submitted some information to the developers, but I donāt have an update to share at the moment.
Iām glad to see this is not an isolated issue only for us, which again points to a deeper issue.
The only thing we did was to increase the leeway a bit, but that doesnāt help when the token is undefined or when itās been expired for longer: Just now, we got a token that had expired 6 days ago. Do you get those too? Those usually come in the query param. The undefined ones and the recently expired ones come more often from fetch.
Hey everyone 
, just following up here in case it helps others who are seeing this.
From our investigation, the āNotBeforeError: jwt not activeā cases are very likely due to system clock not matching ours on either the app host or the merchantās device (if the app is running locally), where the tokenās ānot beforeā time is slightly in the future. Iād just make sure your appās hosting environmentās clock is synced accurately and this should resolve that issue.
For the undefined tokens, these are not expected, but since we donāt see widespread reports of this on our end, our thinking is that they may be implementation-specific. Weāre still keen to investigate, but I do realize that catching one of these when it happens is difficult. If you are at all able to capture a HAR (with sensitive info redacted), please share it here (or ping me if you want to set up a DM) and we can take a look.
I know thatās not the most satisfying answer without a concrete repro, but I wanted to close the loop here, let me know if I can clarify anything on my end as always!
1 Like
@Alan_G, do you know if the AppBridge team can add a test mode we can toggle to generate some expired/invalid tokens at random? What I mean is a mode that will produce invalid tokens say 1/3 of the time, so we can see the effects in action.
Weāre having to develop a whole retry mechanism for invalid tokens on the server side, using the X-Shopify-Retry-Invalid-Session-Request header, but without the ability to produce such invalid sessions, we actually canāt test this behaviour.
Thereās also code in both shopify_app and shopify_api gems that is supposed to deal with invalid tokens, but we canāt test it. We just saw an issue in production where an invalid token triggered the patch_shopify_id_token (link) but Rails complains because this is triggering a double render somewhere else.
Hey @flavio-b, thanks for following up again here - I canāt guarantee any specifics when it comes to feature requests, but I am happy to reach out to our product team to see if they can look at adding a feature.
When it comes to the issues youāre seeing with the Gem libraries, the best thing to do would be to open an issue in those respective repos. Just linking them here for ease of reference:
That said if you have opened an issue there already, or if you do open one and itās been sitting for a few weeks, just ping me here and Iād be happy to take a look for you. Iāll loop back with you in this thread once I have more info to share on the test mode feature request though - hopefully speak with you soon! 
Hi @Alan, thanks for the tips/links, but I think we already have a clear idea of what we need to do. Both of those gems have code paths to handle invalid sessions in some way, and AppBridge is already programmed to expect Shopify-Retry-Invalid-Session-Request.
All that is left is a method for us to test this mechanism, either to observe how the gems behave, or to test any retry implementation we might want to build. For example, we only caught the double render problem because, by chance, a merchant hit an invalid token in production. I canāt open a Github issue nor work on a PR for the gems without being able to replicate the issue, try a potential fix etc.
If it helps build a strong case for this feature, Iād mention this: Since there is a public API for a retry mechanism (via custom header in this case), we ought to be able to easily produce invalid sessions to test such retry mechanism. 
Ultimately I think that fumbling with the authentication layer, custom headers and learning about leeway time config is too low-level and takes time away from the 'application layer". But.., it seems like all of this is necessary, so we want to at least replicate auth issues and make sure the app handles things smoothly.
Thanks for the reply @flavio-b - definitely understand where youāre coming from on this. Iām still in touch with our product team, but donāt have next steps to share yet. Iāll loop back with you once I do and pass along your feedback, appreciate you sending this our way.
1 Like
Hi Alan, do you have an update from the team as to how we can generate invalid tokens to test/trigger the retry behaviour?
We still keep getting daily alerts, merchant tries to open the app andā¦ boom! A red screen with the dreaded 500 code. JWT::DecodeError: Not enough or too many segments.
I noticed a change in the token retrieval logic in AppBridge. That may have calmed down the undefined issue, at least from fetch requests, but I canāt confirm 100%. However, the tokens that come in the URL (mostly from admin link actions) are still a problem.
Iāll have to take that back. Weāre getting several tokens which are null today, in addition to classic undefined ones. Note that these two types originate in Javascript (our backend is Ruby) and we have absolutely no Javascript code that deals with token headers in any way shape or form, so these are all originating from AppBridge logic.
Hi @flavio-b, thanks for the detailed follow-up and for sharing the additional context about the null tokens alongside the undefined ones there, really appreciated as always.
Iāve reached out to some folks internally again with your latest findings and Iāll keep you posted as soon as I hear back from the team. Thanks again for the detailed technical context - itās really helpful.
1 Like
INTERNAL NOTE
https://shopify.slack.com/archives/CG71G24BZ/p1758818836804489
Hi @flavio-b and all, thanks again for your patience on this. There has been some movement on the issue and weāve identified a potential cause for the null/missing JWTs being sent. Iāll keep my eye on things for you and loop back here when I have more concrete info, but I did want to let you know that we are still investigating this.
Hey, @Alan_G, glad to know they found something! I have a feeling the number of undefined and null tokens are a bit less than, say, 1 or 2 months ago. However, we still get them often enough to be disruptive (with the error alerts and all).
Hopefully they can patch whatever is the cause so we can say goodbye to this problem once and for all.
I look forward to any news you can provide on this. Cheers.
1 Like