TEST: Add Selenium tests for session storage cache behavior in Chrome and Firefox, including proxy setup and enhancements to test utilities - #3
Merged
Conversation
… and Firefox, including proxy setup and enhancements to test utilities
The listen loop appends to RequestLog while the test thread enumerates it (CountJsonPosts) and clears it (ResetRequests). A browser-initiated request landing mid-read - a favicon fetch after load, or a late pipeline call - would throw "collection was modified" or return a torn count, failing the test for reasons unrelated to the behaviour under test. ConcurrentQueue enumerates a snapshot instead.
The path the client-side script posts refreshed evidence to is not the same in every web integration, so hardcoding /51dpipeline/json meant the proxy never forwarded that request and the counter never saw it for four of the six languages. Measured in a browser: dotnet and rust post to /51dpipeline/json, java to /51Degrees.core.json, and node, python and php to /json. Each descriptor now declares its own, defaulting to the dotnet path, and both the proxy route and CountJsonPosts read it from there. The lookup goes through the descriptor rather than the running app so it also works for the CI case, where EXAMPLE_URL points at an already-running example. With this, the node and python legs pass in both browsers, cookies on and off. dotnet, java and php still fail the non-cookie legs on the session storage key assertion, which is the released-template gap this test is for.
StartsWith meant the /51Degrees.core.js route also captured /51Degrees.core.json, which is where the java integration posts its refreshed evidence. Java's callback was being proxied through the script route by accident, so it worked but was attributed to the wrong route and could never be counted. A route key ending in '/' still matches everything beneath it; any other key now has to match the path exactly.
AreNotEqual on two session ids only means something when there are ids to compare. An integration that leaves fod.sessionId empty failed with "Expected any value except:<>. Actual:<>", which reads as the include being served from the browser cache when it is really a value the example never supplied, and the test has no way to tell those apart. Both ids are now checked for content first, and an empty one reports Inconclusive naming the language and the two values. That turns the rust example, whose include carries an empty session id, from four confusing failures into four explicit skips, and it gates on the capability rather than on a hardcoded list of languages.
… leg The test read fod.sessionId and window.fodDevice out of the include's own variables, which checks the script's internal state rather than whether fod.complete hands a page usable results. The page now renders the device id, hardware name, platform name and device type into a table the way a customer's page would, and the test reads those cells back. It also captured the first page's device data and never compared it, so a cache returning different but still populated results would have passed. Every rendered value is now compared against the first page. Adds a reload of the second page, so a refresh is covered as well as a navigation, and asserts no json refresh call on the cookie leg too. The comment claiming repeat calls were not stable with cookies was wrong: measured against the pre-fix package, the cookie leg makes a second call and fails, and against the fixed package it makes none and passes.
…cache # Conflicts: # Examples/ExampleApps.cs # Examples/ExampleDescriptor.cs
justadreamer
approved these changes
Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why:
Same scenario as the pipeline-dotnet template tests, but against the real
getting-started web example (EXAMPLE_LANG, dotnet first) and a real cloud.
The test serves its own two pages and proxies the include and pipeline
endpoints to the example, so the page and the endpoints share one origin
like a customer site. The include is proxied with Cache-Control no-store
so every page view fetches it fresh.
The strict assertions (stable keys, no repeated json call) apply to the
non-cookie legs; the cookie legs act as the control that the values
survive in the cookies. The non-cookie legs are red today because the
released packages still carry the previous template. No code change is
expected to turn them green: once the template change ships through the
pipeline packages and the examples bump versions, they go green by
themselves. Keep as draft and do not merge until then, otherwise the red
legs would reach every SDK repo's Contract CI.