Skip to content

promote: daily cookie-session keep-alive (refresh every 24h, for cookie auth) - #106

Merged
ralyodio merged 1 commit into
masterfrom
promote/session-keepalive
Jul 17, 2026
Merged

ralyodio merged 1 commit into
masterfrom
promote/session-keepalive

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

The ask & the reality

"Refresh tokens every 24h." Your social accounts are all auth_mode: cookie with no refresh token — a cookie isn't an OAuth token, so there's nothing to exchange on a schedule. The cookie-auth equivalent of a token refresh is a session keep-alive: reload the site with the current cookies and re-save whatever (rotated, sliding-expiry) cookies it hands back. That extends the session and delays token_expired.

What it does

A worker sweep, at startup + every 24h:

  • For each active cookie account: launch the headless browser with its cookies, load the platform home, and
    • if still logged in → re-save the refreshed cookies (enc_access_token) and stamp session_refreshed_at;
    • if the session has died → flag it token_expired so the UI prompts a reconnect before a scheduled post fails.
  • A 23h per-account gate means worker restarts don't re-warm a session that was just warmed.
  • Transient/navigation errors never flag token_expired (a blip won't nuke a live session).

Changes

  • migration sp_account.session_refreshed_at (applied to prod already)
  • lib/sp/platforms/browser.ts — refreshCookieSession() reusing launchContext/assertLoggedIn
  • lib/sp/sessionRefresh.ts — the sweep (per-platform home URLs, re-encrypt, flag dead)
  • worker/index.ts — schedule (startup + 24h)
  • /promote/accounts — shows "Session kept alive "

Honest limitation

This prevents live sessions from decaying and warns early when one dies. It cannot revive an already-dead session — that still needs a fresh cookie export (e.g. your current linkedin/x). Best results come from having warm cookies to begin with.

Verified

tsc (app + worker) clean · next build compiles /promote/accounts. (Live cookie-extension behavior varies per platform and can only be confirmed running against real sessions.)

🤖 Generated with Claude Code

… cookie auth)

Cookie-auth accounts have no OAuth refresh token to exchange, so a literal
token-refresh job has nothing to call. The cookie equivalent: once a day reload
each active cookie account with its stored cookies and re-save the rotated
(sliding-expiry) cookies the site issues, which extends the session and staves
off premature token_expired. Also proactively flags a session that HAS died so
the user is prompted to reconnect before a scheduled post fails.

- migration: sp_account.session_refreshed_at (gates the 24h cadence across
  worker restarts + surfaces "last kept alive" in the UI)
- lib/sp/platforms/browser.ts: refreshCookieSession() — loads the home URL,
  checks login, returns the context's refreshed cookies
- lib/sp/sessionRefresh.ts: refreshCookieSessions() sweep — per-platform home
  URLs, re-encrypts refreshed cookies, flags dead sessions token_expired;
  never flags on a transient/navigation error
- worker/index.ts: run at startup + every 24h (23h per-account gate)
- promote/accounts: shows "Session kept alive <time>" for active accounts

Limitation: this PREVENTS decay of live sessions and warns early — it cannot
revive an already-dead session (that still needs a fresh cookie export).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.

@ralyodio
ralyodio merged commit a663ab5 into master Jul 17, 2026
8 checks passed
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.

1 participant