Skip to content

build: 1.0.1#4

Merged
bluestreak01 merged 3 commits intomainfrom
v_1_0_1
Feb 3, 2026
Merged

build: 1.0.1#4
bluestreak01 merged 3 commits intomainfrom
v_1_0_1

Conversation

@bluestreak01
Copy link
Copy Markdown
Member

@bluestreak01 bluestreak01 commented Feb 2, 2026

Summary

  • Rename Maven artifact ID from client to questdb-client for better discoverability
  • Update dependency reference in examples module

The published artifact will now be org.questdb:questdb-client instead of org.questdb:client.

Test plan

  • Verify mvn clean install succeeds
  • Confirm artifact is correctly named in local Maven repository

🤖 Generated with Claude Code

@bluestreak01 bluestreak01 changed the title build: rename artifact from client to questdb-client build: 1.0.1 Feb 2, 2026
@RaphDal RaphDal self-requested a review February 2, 2026 20:18
@bluestreak01 bluestreak01 merged commit a828dd2 into main Feb 3, 2026
8 of 11 checks passed
@bluestreak01 bluestreak01 deleted the v_1_0_1 branch February 3, 2026 11:31
jerrinot added a commit that referenced this pull request Mar 4, 2026
bluestreak01 added a commit that referenced this pull request Apr 27, 2026
Re-adds the volatile generation counter (and its companion retry loop in
flushPendingRows) that the cursor strip had removed. This is the
foundation the reconnect work (#20/#21) builds on — the producer needs a
way to detect that the wire-side actor has rotated state mid-encode so
it can discard now-poisoned schema-ID refs and re-encode with full
schema definitions.

What lands here:

  * QwpWebSocketSender: volatile connectionGeneration + lastSeenGeneration
    pair. Bumped on initial recovery from disk (the recovered FSNs were
    never seen by *this* server connection, so the first batch must
    re-publish full schemas). Reconnect path will bump in subsequent
    work.

  * flushPendingRows: encode-mid-reconnect retry loop. Sample gen before
    encode + after finishMessage; if it changed, discard the encoded
    bytes (table buffers haven't been reset yet — source rows are
    intact) and retry with reset schema state. Bounded at
    MAX_SCHEMA_RACE_RETRIES = 10 so reconnect-faster-than-encode
    surfaces a hard error instead of spinning.

  * CursorSendEngine.wasRecoveredFromDisk(): single-bit accessor the
    sender reads during ensureConnected to decide whether to bump.

  * SegmentRing.openExisting: filter out empty hot-spare leftovers
    (frameCount=0) from prior sessions. Those carry the provisional
    baseSeq=0 and would otherwise collide with the real baseSeq=0
    segment and trip the contiguity check. Surfaced by the new
    recovery test — caught a real bug in the recovery scan.

  * Test hooks bumpConnectionGenerationForTest / accessors for gen and
    maxSent*Id so reconnect-effect tests can run without spinning up
    the (still-not-implemented) reconnect path.

Tests cover: gen=0 for fresh connect, gen=1 after disk recovery, gen
bump triggers schema-state reset on the next encode and is sticky
(further flushes without bump don't re-reset).

Spec decisions #4 and #5 land here.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants