Reuse DuckDB path for Quack sync - #930
Conversation
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
Quack now has its own config, environment variables, CLI command group, daemon push route, watch path, and read selector instead of being inferred from PostgreSQL targets. PG sync keeps the PostgreSQL-only URL/schema/machine behavior, while Quack maps to the existing DuckDB backend only at the Quack boundary and derives the internal machine label from the host. This keeps PG and DuckDB behavior separate while making Quack usable where a read-only mirror or push sync backend is expected.
The standalone Quack path made the shared DuckDB push helper URL-aware so Quack could push to a remote endpoint. That also changed regular duckdb push when users had [duckdb].url configured for remote reads, because the helper preferred URL over Path and could try to attach Quack instead of updating the local mirror file. Keep DuckDBPush on the explicit local file opener and reserve URL-aware opening for the Quack push path. A regression test covers configs that include both a local DuckDB path and a remote read URL.
The HTTP push daemon still used URL-aware DuckDB construction for duckdb push, so a posted DuckDB config with a Quack read URL could make the daemon target the remote endpoint while the local CLI backend correctly wrote the local mirror file. The daemon route now opens the posted DuckDB path explicitly, preserving existing duckdb push behavior across direct and daemon modes. Quack push also now owns its sync-state scope at the handler boundary instead of accepting an empty or caller-provided request value. This keeps Quack watermarks separate from the local DuckDB mirror state while preserving project filter handling.
Quack exposes auth_token in the CALL quack_serve result, and SQL-printing launch paths can dump that table into logs. agentsview now starts Quack with the table-function form projected to listen_uri and listen_url, keeping the token as an input argument only instead of requesting it back in the result set. The DuckDB Quack startup summary also stops printing generated token values and reports only whether the token was generated or configured. The Quack smoke path uses the same non-secret projection, and an fd-level integration test covers process stdout and stderr during startup.
140f31b to
e7cbb0c
Compare
roborev: Combined Review (
|
Quack sync should not introduce a parallel config, command, or daemon API when the existing DuckDB backend already owns local-file and remote-URL targets. This collapses the branch-added Quack config and push/read surfaces into DuckDBConfig, so AGENTSVIEW_DUCKDB_URL and AGENTSVIEW_DUCKDB_TOKEN drive remote Quack pushes through the normal duckdb push route. Continuous sync is preserved as duckdb push --watch rather than a top-level quack command, and DuckDB status now opens URL-backed stores through the same config path. Startup output for serve modes now reports that auth is configured without printing bearer token values, because those streams can land in logs.
cpcloud
changed the title
roborev: Combined Review (
|
DuckDB status was moved onto the config-backed store opener so URL-backed Quack endpoints could be queried without a local sync handle. That path accidentally counted every mirrored machine, while the existing DuckDB status output had always reported this machine's session and message counts. Shared mirror files and remote Quack endpoints could therefore show global totals in a per-machine status view. Keep the config-backed status reader on the same machine-scoped queries as Sync.Status, while still allowing the URL-backed store opener to handle remote Quack endpoints. The regression test seeds another machine into the mirror and verifies the status reader does not include it.
roborev: Combined Review (
|
Starting a Quack server with an auto-generated token is not useful once startup output stops printing secrets, because clients have no safe way to discover that token. Persisting the generated value would also create another durable secret sink just to recover from a logging concern. Require the existing DuckDB token path instead: --token, AGENTSVIEW_DUCKDB_TOKEN, or [duckdb].token. Startup output continues to report only that a token is configured, so systemd or terminal logs do not receive bearer-token material.
roborev: Combined Review (
|
Remote Quack pushes reuse the DuckDB sync watermark, so different URL-backed targets could share duckdb_last_push_at. Switching targets after pushing another remote could skip unchanged sessions missing from the new target. Derive a non-secret sync-state scope for URL-backed DuckDB targets and pass it through local, daemon, and server push paths. Local file mirrors keep the historical unscoped key for compatibility, and duckdb status reads the same scoped watermark. Keep the adjacent token handling explicit: Quack serve help no longer promises generated tokens, and Quack URL redaction now strips URL userinfo plus secret-like query values before errors can print them.
roborev: Combined Review (
|
|
looking |
Service managers commonly stop long-running watch commands with SIGTERM rather than an interactive interrupt. DuckDB push watch used the narrower interrupt-only context, so it could exit before the watch loop had a chance to perform its cancellation path and final flush, unlike the PostgreSQL watch flow.
roborev: Combined Review (
|
Native Quack URLs do not parse like HTTP URLs, so userinfo and fragments could survive the existing redaction path even though attach errors include the redacted URL. Strip native userinfo, secret query values, and fragments before logging those endpoints. The auth recovery prompt also needs to reference token sources available before browser authentication succeeds. Point it at the persisted config token or AGENTSVIEW_AUTH_TOKEN instead of the server console or settings page, which may be unavailable in auth-required mode.
roborev: Combined Review (
|
Roborev flagged several low-risk follow-ups across the DuckDB/Quack path: duplicated status-count SQL, stale docs for explicit Quack serve tokens, incomplete remote-scope coverage, and an inconsistent signal helper. Centralize DuckDB status counting through the config-backed helper, keep non-secret selector query parameters in remote target fingerprints, document that Quack serve tokens must come from the existing DuckDB token sources, and reuse one DuckDB long-running signal set for push and serve commands.
The auth recovery flow now points users at AGENTSVIEW_AUTH_TOKEN, so the server config loader needs to treat that variable as a real token source instead of allowing config.toml to silently override it. This keeps supervised deployments and pre-auth browser recovery consistent with the documented token lookup path. Refresh the Zensical docs for the same PR behavior: DuckDB push watch, URL-backed DuckDB push/status/serve, explicit Quack serve tokens, and auth tokens no longer being printed to startup output.
be8e3cc to
20a9b98
Compare
roborev: Combined Review (
|
…949) parse-diff v1 (#662) rejected Warp, Forge, and Piebald because their sync phases had woven-in change detectors and no `DiscoverFunc`. The provider facade (#876–#885, #924) made that reason obsolete — all three now have a unified `Discover()` via `dbBackedProviderFactory` — but both parse-diff gates still keyed on `FileBased`, which is false for these shared-SQLite stores. This relaxes the two gates (`parseDiffAgentDiscoverable`, `parseDiffAgentSupported`) to admit provider-authoritative agents with registered factories, instead of flipping `FileBased`: that flag is read at nine-plus other sites (watcher, sync engine, token accounting, remote sync, SSH resolve, settings) and genuinely means "reads a literal per-session file", so flipping it would change unrelated behavior. Two hazards the wider gate exposed are handled in the same change: - Virtual `<db>#<sessionID>` sources cannot be stat'd, so the raced-skew reclassification from #805 would have masked every real drift on these agents as "raced". `stripVirtualSourceSuffix` now knows their DB filenames and `parseDiffSourceReliableForRaced` re-requires `FileBased`, so DB-backed agents fail closed toward reporting a change rather than masking one. - These providers discover one source per session (like OpenCode, unlike per-DB Kiro), so `--limit` presence-keying moved to a shared per-session base list; sessions cut by `--limit` now report "not sampled" instead of false-positive presence findings. Quack (#930) is out of scope: it is the DuckDB remote-sync transport, not a registry agent with session sources to re-parse. `--limit` ordering: the provider stamps each session's real mtime onto an additive, advisory `SourceRef.DiscoveryMTimeNS` while `Discover()` already has the store's session metas in hand, and the parse-diff sampler prefers it over the failed-stat fallback — so limited runs sample these virtual sources newest-first like file-based agents. The field is ordering-only metadata; skip-cache and data-version freshness still resolve through `Fingerprint`, and the raced-guard is unchanged. Where to look: `internal/sync/parsediff.go` (gate, raced predicate, per-session base keying) and `internal/sync/parsediff_dbbacked_test.go` for the end-to-end coverage. Co-authored-by: Matthew Jacobs <mjacobs@users.noreply.github.com>
2 participants
Quack sync now uses the existing DuckDB configuration and command/API paths instead of a parallel Quack config surface.
AGENTSVIEW_DUCKDB_URLandAGENTSVIEW_DUCKDB_TOKENdrive remote Quack pushes throughagentsview duckdb push, andduckdb push --watchpreserves continuous sync on the same backend path. The daemon route remains/api/v1/push/duckdb; there is no separate/push/quack,[quack], orAGENTSVIEW_QUACK_*path.Remote URL-backed DuckDB/Quack pushes now use a per-target sync-state scope derived from a non-secret URL fingerprint, so switching remotes does not reuse another target's
duckdb_last_push_atwatermark. Local DuckDB file mirrors keep the historical unscoped watermark for compatibility, andduckdb statusreads whichever scope matches the configured target.Quack-specific code remains only at the protocol boundary: DuckDB remote attach/opening and
agentsview duckdb quack serve, which starts DuckDBquack_serve. Serve startup projectsquack_serveresults down to listen fields and all serve startup paths now report auth state without printing bearer token values, because stdout and service-manager output can become logs.duckdb quack serverequires an explicit token from--token,AGENTSVIEW_DUCKDB_TOKEN, or[duckdb].tokenrather than generating a hidden or persisted token; Quack URL redaction also strips URL userinfo and secret-like query values before attach errors can print them.The auth recovery path now also treats
AGENTSVIEW_AUTH_TOKENas an actual token override, so supervised deployments can recover browser auth without relying on printed startup tokens.duckdb statusalso uses the config-backed DuckDB/Quack opener while preserving the existing machine-scoped DuckDB session and message counts, so shared mirrors and remote Quack endpoints do not report global totals for the local machine view.The tradeoff is that Quack is treated as DuckDB remote transport rather than a new storage backend. That keeps query behavior aligned with the DuckDB mirror while still supporting remote Quack push/read workflows through the existing DuckDB surface.