Support Seq servers that do not expose the Scan link

[aarondglover]

Summary

This keeps SeqSearch working against older Seq servers that do not expose the Scan link on api/events/resources, and updates the project/tests to .NET 10.

Problem

SeqSearch() currently uses conn.Events.EnumerateAsync() unconditionally. On older Seq servers, that path throws:

System.NotSupportedException: The requested link `Scan` isn't available on entity `Seq.Api.Model.ResourceGroup`.

That breaks MCP search even though the server is otherwise reachable and event reads still work.

Findings

I reproduced this against a local datalust/seq:2024.3.13181 container:

• api/events/resources does not expose Scan
• SignalList still works
• direct reads from api/events still work
• SeqSearch fails because Events.EnumerateAsync() expects Scan

I also verified that simply updating the Seq.Api package from 2025.2.0 to 2025.2.2 does not resolve the issue on Seq 2024.3.13181.

For comparison, a newer Seq server (2025.2.16202) does expose Scan, and the existing EnumerateAsync() path works there.

Resolution

This change adds a targeted fallback in SeqSearch():

• try Events.EnumerateAsync() first
• if Seq throws NotSupportedException for the missing Scan link, fall back to Events.PagedEnumerateAsync()

That preserves the preferred path on newer Seq versions while keeping older 2024.3.x servers functional.

Additional changes

• update the main project and test project to net10.0
• update the integration test path to the net10.0 server output
• make the search integration test deterministic by writing a test event first
• add a compatibility-focused integration test for the old Seq path
• document the compatibility behavior in README.md and docs/DEVELOPMENT.md

Verification

Validated locally with:

dotnet build SeqMcpServer.sln -c Debug
dotnet test SeqMcpServer.sln -c Debug --no-build

Compatibility checks performed during investigation:

• Seq 2024.3.13181:
  • upstream code path fails with missing Scan
  • Seq.Api bump alone still fails
  • fallback to PagedEnumerateAsync() succeeds
• Seq 2025.2.16202:
  • Scan is present
  • EnumerateAsync() succeeds as before

Notes

I kept the fallback narrow to the specific Scan-link compatibility failure so newer servers continue to use the primary enumeration path unchanged.

[aarondglover]

@willibrandon hope you can merge when get a spare moment to review. This is breaking some of my CI pipelines. You were Soo quick to realise the benefit of seq integration with AI! It's an indispensible part of my debugging and bug fixing workflows! THANKYOU!

[willibrandon]

Hey @aarondglover — apologies for the delay on this. I genuinely hadn't seen any of the issues or PRs on this repo until just now (head buried in other projects). Taking a proper look at everything today, and yours is at the top of the list given it's blocking your CI. Thanks for the thorough write-up and the kind words. More shortly.

[aarondglover]

Please don't apologise - it hasn't been a long wait yet. I Just figured I would mention your name explicitly as those other pr notifications and emails are easy to miss!

[willibrandon]

Looks good overall — this lands a real fix. Two small thoughts inline.

One open question on the test side: once the fallback path is reliably exercised by the legacy fixture, we lose Scan-path coverage against current Seq builds. Worth pairing with a second fixture pinned to a 2025.x build that does expose Scan? An abstract base parameterized by image plus two thin derived classes (_LegacySeq, _ModernSeq) is a small change. Happy to take that as a follow-up if you'd rather keep this PR scoped tight.

[willibrandon]

Could we probe instead of catching here? SeqConnection : ILoadResourceGroup is public, and a ResourceGroup's Links is a case-insensitive dict — Links.ContainsKey("Scan") upfront lets us route deterministically without leaning on the exception's message. Cheap to do because Seq.Api caches the resource group on the connection, so the probe doesn't add a round-trip.

[aarondglover]

No exception handling as control flow now, specifically probes for scan method and uses appropriate path

[willibrandon]

One thing I noticed: the fixture above pins datalust/seq:2024.3 (floating tag), which on my machine resolves to a patch newer than 13181 that does expose Scan — so this test and the smoke test above are both silently going through the Scan path rather than the fallback. Pinning to datalust/seq:2024.3.13181 (the build you confirmed lacks it) would make the no-Scan coverage real, and at that point this dedicated fallback test becomes redundant with the regular search test.

[aarondglover]

Now pinned

[aarondglover]

Looks good overall — this lands a real fix. Two small thoughts inline.

One open question on the test side: once the fallback path is reliably exercised by the legacy fixture, we lose Scan-path coverage against current Seq builds. Worth pairing with a second fixture pinned to a 2025.x build that does expose Scan? An abstract base parameterized by image plus two thin derived classes (_LegacySeq, _ModernSeq) is a small change. Happy to take that as a follow-up if you'd rather keep this PR scoped tight.

Thanks — good point. You’re right that with the legacy fixture exercising the fallback path, we’d no longer be validating the Scan path against current Seq builds. I agree it’s worth adding a second fixture pinned to a modern 2025.x image, and the abstract base + two thin derived classes approach seems like a clean way to do it. I’ll add that here.