feat(website): add new collections analysis mode to W-ASAP

[fhennig]

resolves #1006

Summary

Add a new 'Collection' analysis mode, where you can select a cov-spectrum collection to analyze, meaning you can see the prevalence of the defined variants over time.

Specific changes:

• New CollectionAnalysisFilter component to be used in the WasapPageStateSelector.
• useWasapPageData was extended to also fetch the collections. During this, the file was also refactored entirely.
• eslint config updated, somehow it was checking node_modules and dist as well?
• the new mode is only enabled in staging.

Screenshot

Screen.Recording.2026-02-05.at.10.09.52.mov

Follow-ups

The generation of the coverage queries still needs to be implemented: #1026 (there is a TODO in the code)

I left some of the refactoring for later, as it's not urgent and I didn't want to put too much into this PR: #1025

Another follow-up: We want to implement a filter for the collections that are shown: #1027

Useful links

https://github.com/GenSpectrum/cov-spectrum-server/blob/develop/docs/api.md

PR Checklist

• All necessary documentation has been adapted.
• The implemented feature is covered by an appropriate test.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
dashboards	Ready	Preview, Comment	Feb 6, 2026 10:00am

[fengelniederhammer]

While testing, I found this:

curl 'https://lapis.wasap.genspectrum.org/covid/component/queriesOverTime' \
  -X POST \
  -H 'Accept: */*' \
  -H 'Content-Type: application/json' \
  -H 'Priority: u=4' \
  --data '{"filters":{"locationName":"Zürich (ZH)","samplingDateFrom":"2025-12-21","samplingDateTo":"2025-12-27"},"queries":[{"displayLabel":"Delta","countQuery":"nextstrainClade:20a | nextstrainClade:20i | nextstrainClade:20j","coverageQuery":"!C20N | !C20N | !C20N"},{"displayLabel":"Early Omicron","countQuery":"nextstrainClade:21m | nextstrainClade:21k","coverageQuery":"!C21N | !C21N"},{"displayLabel":"23I / BA.2.86 except JN.1","countQuery":"nextstrainClade:23I & !nextcladePangoLineage:JN.1*","coverageQuery":"!C23N | !C1N"}],"dateRanges":[{"dateFrom":"2025-12-15","dateTo":"2025-12-21"},{"dateFrom":"2025-12-22","dateTo":"2025-12-28"}],"dateField":"samplingDate"}'

returns a 500 error:

"org.genspectrum.lapis.controller.BadRequestException: Failed to parse advanced query (line 1:62): extraneous input 'j' expecting <EOF>."

• Why is this a 500 and not a 400 when an advanced query fails to parse?
• Why is it invalid at all?

(from /swiss-wastewater/covid?locationName=Zürich+(ZH)&samplingDate=2025-12-21--2025-12-27&granularity=week&analysisMode=collection&collectionId=28092&)

[fengelniederhammer]

A lot of other collections show this (e.g. collection 211):

Is that expected?

[fhennig]

Thanks Fabian! Regarding the query parsing:

So, I've made a mistake, by assuming I can just use any variant query as a LAPIS advanced query. They query syntax for both of them has an overlap, but not all variant queries are advanced queries, and vice versa.

I spoke to Chaoran about this, and he said that we should check each variant query and if it isn't a valid advanced query (i.e. we can't use it in LAPIS) we discard it from the collection. This is of course not ideal, but by doing this, we get to use at least some of the cov-spectrum collections. This requires the LAPIS endpoint to validate queries, so we can check if a variant query is valid or not.

Since there is already a TODO related to this blocking LAPIS feature, I'd for now add another TODO in the code that this is a know limitation for now, and then we can tackle both of these things once we have the LAPIS endpoint.

The other thing you mentioned:

A lot of other collections show this (e.g. collection 211): [screenshot]

Is related to this, in that variants don't perfectly match to queries we can use. I'm only using variants from collections that are defined by a variantQuery. Collection 211 doesn't have any variants that are defined in this way, so we end up with an empty list of queries.

I'm not sure how many collections are defined like this, but it is expected that a lot of them won't work. That's also why we want to specifically filter for wastewater collections as a follow-up task.

The specific collection you mentioned defines the variants via the lineage property on the sequences. This can't be applied to wastewater sequences, because the amplicon sequences we have are not assigned to a lineage (they are often too short to confidently assign a linage to them).

--

I hadn't considered it that much before, but now I see that in its current form this feature isn't very useful. I still think it makes sense to maybe postpone the two things above to a future PR, to keep this one kind of small? This one sets up all the 'plumbing' to connect stuff together, in that way I think it's fine to have it as a separate PR. But if you disagree, I can also keep this one open and we do the LAPIS endpoint and the filtering in this PR as well.

(The other stuff you've flagged I will of course fix in this PR!)

[fengelniederhammer]

Sounds good to me. Getting it fully functional can be done in later PRs, since this is only on staging for now anyway 👍

[fhennig]

I've changed the way the staging switch works here: 23e50b0