Skip to content

feat(discovery_kit_sdk): bump index revision on register/clear#181

Merged
joshiste merged 3 commits into
mainfrom
feat/bump-index-revision
Jul 10, 2026
Merged

feat(discovery_kit_sdk): bump index revision on register/clear#181
joshiste merged 3 commits into
mainfrom
feat/bump-index-revision

Conversation

@joshiste

Copy link
Copy Markdown
Member

What

Register and ClearRegisteredDiscoveries now call exthttp.BumpRevision() so the extension index ETag reflects the registered discoveries/target describers/attribute describers/enrichment rules.

The runtime Discover (discovered-targets) endpoint keeps its own existing IfNoneMatchHandler(LastModified()) ETag — that's a different endpoint and is intentionally untouched.

Why

Part of centralizing index-response caching in the SDKs (see steadybit/extension-kit#158). The index ETag becomes registration-scoped instead of frozen at process start.

Depends on

steadybit/extension-kit#158exthttp.BumpRevision is introduced there. CI on this PR is red until extension-kit is tagged; I'll bump go.mod/go.sum to the new tag as a follow-up commit.

Call exthttp.BumpRevision() from Register and ClearRegisteredDiscoveries so
the extension index ETag reflects the set of registered discoveries, target
describers, attribute describers and enrichment rules, enabling the agent's
index-response cache to invalidate on registration changes without a process
restart. The runtime Discover endpoint's own ETag is left unchanged.
@claude

claude Bot commented Jul 10, 2026

Copy link
Copy Markdown

Claude finished @joshiste's task in 1m 5s —— View job


Reviewing PR #181

  • Check previously unresolved review threads for fixes (none existed)
  • Review new changes (correctness, security, perf, concurrency, typos)
  • Post final review

Review

This is a small, focused change and looks correct.

  • Register (go/discovery_kit_sdk/discovery_kit_sdk.go:73) calls exthttp.BumpRevision() only after a successful match, i.e. after the panic branch for unknown discovery types — so a failed registration correctly won't bump the revision.
  • ClearRegisteredDiscoveries (go/discovery_kit_sdk/discovery_kit_sdk.go:220) bumps after resetting all four registries, consistent with the description.
  • The runtime Discover endpoint's own IfNoneMatchHandler(LastModified()) is untouched, matching the PR description.
  • go.mod/go.sum are already bumped to extension-kit v1.11.0, so the "CI is red until tagged" caveat in the PR description appears resolved — CI (ci workflow) is currently running rather than failing.
  • revision_test.go is well-written: it correctly documents why a unique discovery ID (revision-test) is required (routes are registered on the process-global http.DefaultServeMux and are never removed by ClearRegisteredDiscoveries), and asserts the revision actually changes for both Register and ClearRegisteredDiscoveries.

No bugs, security issues, race conditions, or typos found. No concurrency issues introduced beyond what already existed in the package-level registries (unchanged by this PR).

@steadybit steadybit deleted a comment from johannes Jul 10, 2026
Registration installs routes on the process-global http.DefaultServeMux and
ClearRegisteredDiscoveries does not remove them, so reusing the shared example
id panicked on a duplicate route when the full package ran.
@sonarqubecloud

Copy link
Copy Markdown

@joshiste joshiste merged commit 37c94fe into main Jul 10, 2026
8 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators Jul 10, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant