Skip to content

Auto-update StatusLine until newly-published nanopub is verified#462

Merged
tkuhn merged 1 commit into
masterfrom
speed-up-statusline-verification
May 13, 2026
Merged

Auto-update StatusLine until newly-published nanopub is verified#462
tkuhn merged 1 commit into
masterfrom
speed-up-statusline-verification

Conversation

@tkuhn
Copy link
Copy Markdown
Contributor

@tkuhn tkuhn commented May 13, 2026

Summary

  • Today the StatusLine on the explore page renders the verification status once at page load and never updates. For a just-published nanopub the registry has not indexed yet, so users see "This nanopublication doesn't seem to be properly published (yet). This can take a minute or two…" and have to reload manually. Worse, the empty response is then cached for 60s, so a quick reload shows the same stale message.
  • Hold the render state in instance fields read through lambda IModels and, when the initial response is unverified, attach an AjaxSelfUpdatingTimerBehavior that invalidates the cache via ApiCache.clearCache(queryRef, 0) and re-queries every 3 seconds. Stop once verification succeeds (latest / newer-version / retracted) or after a 2-minute hard cap.
  • Already-verified initial renders keep the previous behavior — no timer attached, no extra registry traffic.
  • Enable and fix the previously-commented StatusLineTest cases so they exercise the rendering paths for empty / newer-version / multiple-newer-versions / retracted responses (uses valid trusty URIs for ListView item rendering).

Why this is safe

  • Verified-on-first-render is the common path and is untouched.
  • Polling is bounded: per-viewer ~40 ticks over 2 minutes, capped by POLL_TIMEOUT_MS.
  • Cache invalidation per tick is O(1) and ApiCache.isRunning already prevents concurrent refreshes.

Test plan

  • mvn -o test -Dtest=StatusLineTest — 5/5 passing (empty / single-newer / multiple-newer / retracted / createComponent).
  • Full mvn -o test suite still green (687 tests).
  • Manual: publish a nanopub, watch DevTools → Network. First Ajax POST returns "doesn't seem to be properly published"; subsequent POSTs fire every ~3s; one of them flips the panel to "This is the latest version." without a page reload.
  • Manual: open the explore page for an already-verified nanopub — no periodic POSTs in the network tab.

🤖 Generated with Claude Code

The previous StatusLine rendered the verification status once at page
load and never updated. For freshly-published nanopubs the registry
usually has not indexed yet, so users saw "doesn't seem to be properly
published (yet)" and had to manually reload — and even then, the empty
result was cached for 60s.

Hold the rendered state in instance fields read via lambda IModels and,
when the initial response is unverified, attach an
AjaxSelfUpdatingTimerBehavior that invalidates the cache and re-queries
every 3s. Stop once verification succeeds or after a 2-minute hard cap.
Verified-on-first-render keeps the previous behavior with no polling.

Also enable and fix the previously-commented StatusLineTest cases so
they exercise the rendering paths for empty/newer-version/retracted
responses.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@tkuhn tkuhn merged commit fd7bd91 into master May 13, 2026
8 checks passed
@tkuhn tkuhn deleted the speed-up-statusline-verification branch May 13, 2026 09:40
@github-actions
Copy link
Copy Markdown

🎉 This PR is included in version 4.28.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant