fix(google): treat HTTP 204 No Content as success in GoogleApi.call by KrisBraun · Pull Request #214 · plotday/plot

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-22T14:10:46Z

Problem

The Google Calendar connector logs a recurring warning on every watch renewal:

[WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204:
[WARN] Failed to stop old watch for kris.braun@gmail.com: Error: HTTP 204:

This is a false alarm — the old watch is being stopped successfully.

Root cause

GoogleApi.call() only treated HTTP 200 as success. Google's channels/stop endpoint returns 204 No Content on success. A 204 fell through to the default branch and threw HTTP 204: (empty body), which setupCalendarWatch catches and logs as a warning on every renewal.

Net effect: success misclassified as an error → log noise on every renewal, and any genuine future failure of that call would be indistinguishable.

Fix

Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is unchanged.

Sibling sweep

Connector	Status
google-calendar	✅ Fixed (reported bug)
google-drive	✅ Fixed — identical bug: same `200`-only handler + a `channels/stop` (204) call logging `Failed to stop drive watch…`
ms-teams	Already correct (`case 204`)
outlook-calendar	Already correct (`200/201/204`)
google-contacts	`200`-only but no 204-returning endpoint in use — latent only, left untouched

Tests

Adds vitest coverage for both connectors' GoogleApi.call (204 → null, 200 → parsed JSON, 410 → null, 5xx → throws). Wrote the 204 test first to reproduce the exact HTTP 204: throw, then fixed it.

pnpm test ✅ (both connectors)
pnpm exec tsc --noEmit ✅
plot lint ✅

No changeset (connectors aren't published to npm; only twister/ requires one).

🤖 Generated with Claude Code

Google's channels/stop endpoint returns 204 No Content on success, but GoogleApi.call only handled status 200 — a 204 fell through to the default branch and threw `HTTP 204: ` (empty body). setupCalendarWatch caught that and logged a spurious warning on every watch renewal: [WARN] Failed to stop old watch for kris@plot.day: Error: HTTP 204: The watch was actually being stopped fine; the success was misclassified as an error, producing noise on every renewal and masking any genuine future failure of the call. Handle the full 2xx success range: return null for empty-body successes (204/205), parse JSON otherwise. Existing 200/400/401/410 behavior is preserved. google-drive's GoogleApi had the identical bug (same 200-only handler + a channels/stop call logging "Failed to stop drive watch…"), fixed the same way. ms-teams and outlook-calendar already handle 204 correctly. Adds vitest coverage for both connectors' GoogleApi.call (204/200/410/5xx). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

KrisBraunand others added 2 commits June 22, 2026 10:10

chore: update lockfile for vitest devDependency
6d359f8
Adds the google-calendar connector's new vitest devDependency to pnpm-lock.yaml so CI's `pnpm install --frozen-lockfile` passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 4cc2a31 into mainJun 22, 2026
1 check passed

KrisBraun deleted the fix/google-api-204-no-content branch June 22, 2026 14:21

Uh oh!

Conversation

KrisBraun commented Jun 22, 2026

Problem

Root cause

Fix

Sibling sweep

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 22, 2026

Problem

Root cause

Fix

Sibling sweep

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 22, 2026

Problem

Root cause

Fix

Sibling sweep

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 22, 2026

Problem

Root cause

Fix

Sibling sweep

Tests

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

KrisBraun commented Jun 22, 2026

Problem

Root cause

Fix

Sibling sweep

Tests