feat: LinkedIn POSSE syndication for blog, newsletter, podcast

[byte-the-bot]

Review Brief

What changed and why

Adds LinkedIn POSSE syndication for blog posts, weekly newsletters, and podcast episodes, mirroring the existing Bluesky pipeline. A post-Fly-Deploy GitHub Action (linkedin.yml) scans each content directory, posts new items to Corey's personal LinkedIn profile via the REST /rest/posts API, writes linkedin_url: back into markdown frontmatter, and commits to main using the App token. OAuth tokens are stored encrypted in a new LinkedInUsers table (mirroring the Google integration), lazily refreshed at publish time and proactively by a server-side cron job every 6 hours. The existing POSSE pattern — scan → skip-if-already-syndicated → publish → write frontmatter → commit — is preserved exactly.

Architecture decisions and trade-offs

• DB-backed CSRF state instead of SignedCookieJar: The plan specified signed cookies, but the codebase has no existing SignedCookieJar usage. The implementation uses a LinkedInOauthStates table (same pattern as LinearOauthStates), with a 10-minute TTL enforced at query time. Functionally equivalent CSRF protection, no new dependencies.
• AppState.linkedin: Option<LinkedInConfig>: Partial config (exactly one env var set) returns Err at boot. Both-absent returns Ok(None), allowing the Fly container to boot before secrets are added. This prevents the PR from creating a deploy-blocking crash loop.
• Cron errors swallowed at Job::run: RefreshLinkedInToken::run wraps do_refresh in if let Err(e) = ... { tracing::error! } and always returns Ok(()). Correct — propagating an error would crash the server via cja::cron::Worker. Token expiry is expected operational state, not exceptional.
• DB state race guard: publish_and_write re-parses frontmatter (not a raw contains() check) after posting to detect a write race. On race, logs at tracing::error! with the orphaned LinkedIn URN/URL so it's recoverable from workflow logs.
• Clap subcommand naming: Variant is PublishLinkedin (single capital L) with #[command(name = "publish-linkedin")] explicit annotation, avoiding heck's publish-linked-in derivation.

Risk assessment

• Blast radius: New tables (LinkedInUsers, LinkedInOauthStates), new AppState field (linkedin: Option<LinkedInConfig>), new CLI command, new cron job, new admin routes, new workflow, new optional fields on BlogFrontMatter and PodcastFrontMatter. Server continues to boot and function if LinkedIn secrets are absent. The from_dir sibling-file filter must ship before any linkedin.md files enter the repo (they're written only by the CLI after it lands, so the ordering is safe).
• Confidence level: High — the implementation closely follows two proven patterns (Bluesky POSSE + Google OAuth), all cargo test --workspace passes (187 server tests), clippy/fmt clean.
• Rollback safety: Yes — migration down drops both tables cleanly. The Option<LinkedInConfig> field means removing the env vars instantly disables all LinkedIn-specific paths without a revert. The workflow can be disabled independently.

Spot-check suggestions

• server/src/commands/linkedin.rs:publish_and_write — after a detected race the function logs the orphaned URN at tracing::error! and returns Ok(false). Confirm the LinkedIn post we just created is indeed loggable-and-recoverable: the urn and web_url are included in the error message, so manual cleanup is possible from workflow logs. Good.
• server/src/http_server/admin/linkedin_auth.rs:linkedin_auth_callback — the DB state DELETE (which also sweeps stale rows) runs before the token exchange POST. If the exchange fails, the state row is already gone, which is correct (user restarts the flow). Verify this is the intended ordering.
• server/src/linkedin.rs:refresh_linkedin_token — both encrypted_access_token and encrypted_refresh_token (plus their expiry timestamps) are written back in the UPDATE. Confirmed: the SQL updates all four columns. Correct.
• server/src/jobs/refresh_linkedin_token.rs:do_refresh — the 30-day tracing::warn! fires when refresh_token_expires_at < Utc::now() + 30 days. Confirm this warning is also surfaced in the admin dashboard panel (the plan specifies a visible warning; check server/src/http_server/admin/mod.rs for the < NOW() + INTERVAL '30 days' check).
• db/migrations/20260523234949_AddLinkedInUsers.down.sql — drops LinkedInOauthStates before LinkedInUsers. Neither table references the other via FK, so order is irrelevant, but worth a quick skim to confirm no FK was accidentally added.

What the agent verified

• cargo test --workspace passes (187 server tests + posts tests, including new linkedin::tests and commands::linkedin::tests)
• cargo clippy --all-targets --all-features --workspace --tests -- -D warnings passes
• cargo fmt --check passes
• ./scripts/auto-fix-all.sh produces no diff
• .sqlx/ offline cache regenerated and committed alongside the migration

---

Summary

Adds LinkedIn POSSE (Publish on your Own Site, Syndicate Elsewhere) syndication for blog posts, weekly newsletters, and podcast episodes. Mirrors the existing Bluesky pipeline.

• Post-Fly-Deploy GitHub Action scans each content directory, posts new items to Corey's personal LinkedIn profile, writes linkedin_url: back into the markdown frontmatter, commits to main via App token.
• OAuth tokens stored encrypted in a new LinkedInUsers table (mirrors the Google integration). Lazy refresh at publish time + proactive 6h cron job.
• New admin OAuth flow at /admin/auth/linkedin and dashboard panel showing expiry warnings.
• Custom post body via sibling linkedin.md file, then frontmatter linkedin_content, then first paragraph of the markdown body. Footer always "New post on coreyja.com\n".

Files

New:

• db/migrations/20260523234949_AddLinkedInUsers.{up,down}.sql — LinkedInUsers + LinkedInOauthStates tables
• server/src/linkedin.rs — HTTP client + token refresh + extract_first_paragraph / compose_linkedin_body / linkedin_urn_to_web_url helpers
• server/src/commands/linkedin.rs — publish-linkedin CLI command + per-kind scanners/classifiers/publishers
• server/src/jobs/refresh_linkedin_token.rs — proactive token-refresh cron job (6h interval)
• server/src/http_server/admin/linkedin_auth.rs — /admin/auth/linkedin + callback
• .github/workflows/linkedin.yml — runs after successful Fly Deploy, three publish steps with continue-on-error

Modified:

• posts/src/{blog,podcast}.rs — linkedin_url + linkedin_content frontmatter fields, sibling-file filter in from_dir
• server/src/state.rs — linkedin: Option<LinkedInConfig> in AppState
• server/src/{main,cron}.rs, server/src/jobs/mod.rs, server/src/commands/mod.rs, server/src/http_server/{routes,admin/mod,test_helpers}.rs — wire everything up

Deviations from the approved plan

1. DB-backed CSRF state instead of signed cookies. The plan called for SignedCookieJar but the codebase has no existing usage of it (would require enabling new axum-extra features). The existing Linear OAuth flow uses a DB-backed state pattern (LinearOauthStates); I mirrored it as LinkedInOauthStates. Functionally equivalent CSRF protection, no new dependencies.
2. #[allow(clippy::doc_markdown)] at file/module scope on the new LinkedIn files instead of backticking every "LinkedIn" mention in doc comments. "LinkedIn" is a proper noun appearing dozens of times in docs; the allow is more pragmatic.
3. A few unrelated whitespace changes in server/src/{bluesky,commands/{bluesky,buttondown},http_server/pages/podcast}.rs, posts/src/notes.rs were applied by the project's scripts/auto-fix-all.sh (cargo fmt). They are pure formatting, not behavior changes.

Required repo secrets (set BEFORE workflow first runs)

• LINKEDIN_CLIENT_ID, LINKEDIN_CLIENT_SECRET (LinkedIn Developer Portal)
• DATABASE_URL (Neon connection string — same value Fly uses)
• ENCRYPTION_SECRET_KEY (same value Fly uses — required to decrypt tokens)
• APP_ID, APP_PRIVATE_KEY (already used by bluesky.yml)

Corey also needs to create the LinkedIn Developer app, add "Sign In with LinkedIn using OpenID Connect" + "Share on LinkedIn" products, set redirect URI to https://coreyja.com/admin/auth/linkedin/callback, and complete the /admin/auth/linkedin flow once after deploy to seed the LinkedInUsers row.

Pre-merge sanity checks

• Confirm LINKEDIN_CUTOFF_DATE = "2026-05-23" in server/src/commands/linkedin.rs is the actual merge day; bump if it slipped.
• Verify LINKEDIN_VERSION_HEADER = "202602" in server/src/linkedin.rs is still within the last 6 months at https://learn.microsoft.com/en-us/linkedin/marketing/versioning .

Test plan

• cargo test --workspace passes (187 server tests + posts tests all green, including new linkedin::tests and commands::linkedin::tests)
• cargo clippy --all-targets --all-features --workspace --tests -- -D warnings passes
• cargo fmt --check passes
• ./scripts/auto-fix-all.sh produces no further diff

[byte-the-bot]

Review after 94 days parked — one fix pushed, one decision needed before merge

Picked this up off the stale-PR queue (oldest CLEAN+green PR in the backlog). CI green, mergeable, 1 commit behind main. Reviewed the OAuth flow, the refresh job, the idempotency path, and the workflow.

Short version: the code is in good shape. One race I fixed, one editorial decision only you can make, and a handful of notes that are fine to merge with.

---

Fixed in a56dc37 — dropped push silently causes duplicate LinkedIn posts

linkedin_url in the frontmatter is the only record that a post already exists on LinkedIn. The commit step was:

git commit -m "Add linkedin_url to syndicated posts"
git pull --rebase origin main
git push

No failure handling. A rejected push drops the idempotency record, and the next run re-publishes → duplicate on your professional profile.

The part that makes this likely rather than theoretical: bluesky.yml chains off the same workflow_run: ["Fly Deploy"] completion, and its concurrency group is bluesky-publish while this one is linkedin-publish — so they don't serialize against each other. Both build a release binary first, then rebase-and-push frontmatter to main. Their push windows line up routinely. Whichever loses gets a rejected push, and only LinkedIn pays for it with a visible duplicate.

Fixed with a bounded rebase-and-push retry (5 attempts, linear backoff, git rebase --abort between attempts). If all five fail it emits a ::error:: naming the exact consequence and the manual remedy, rather than failing silently. Simulated all three paths (transient rejection → success, persistent rejection → exit 1, nothing-to-commit → early exit 0).

---

Needs your call before merge — the cutoff date is 94 days stale

/// Cutoff date — confirm/update at PR-open time; must be the actual merge day.
const LINKEDIN_CUTOFF_DATE: &str = "2026-05-23";

The code's own contract says this must be the merge day. Merging today makes it 94 days early.

I checked what actually falls in that window against current main — it's exactly one post:

BLOG:       1  →  2026-05-27  blog/look-ma-no-ai/index.md
NEWSLETTER: 0     (latest weekly is 2026-04-07, before the cutoff)
PODCAST:    0

So this is a one-line decision, not a spam risk:

• Want "Look Ma, No AI" on LinkedIn? Merge as-is.
• Don't? Bump the constant to the merge day, or add linkedin_url: to that post's frontmatter to mark it as already-handled.

I deliberately didn't pick for you — which of your posts goes on your professional profile is editorial.

---

Notes — not blocking, filed so they're known rather than discovered

At-least-once publishing is structural. The POST happens before the frontmatter write, so any failure in between (write error, or the push failing all 5 retries now) duplicates on retry. The race guard re-reads and re-parses the file after POSTing and logs an orphaned URN at error! — that's the right handling and I'm not asking for more. Bluesky POSSE has the same shape; flagging so it's a known property, not a surprise.

refresh_token and refresh_token_expires_in are required fields on LinkedInTokenResponse. LinkedIn only issues refresh tokens to apps approved for programmatic refresh tokens; without that approval the token response omits them and deserialization fails with "Failed to parse token response". That's a loud failure at connect time rather than a silent one, which is the right side to fail on — just know that's what that error means if you hit it.

Refresh-token expiry is a tracing::warn! only. 30-day heads-up on a 365-day token, into logs. If it lapses, syndication stops until you re-auth. The failed run will go red so you'd notice, but a push notification would be the reliable version.

SELECT ... FROM LinkedInUsers LIMIT 1 with no ORDER BY in the refresh job. Unique index on user_id means one row per user, so with multiple admins you'd refresh a nondeterministic one and only one. Single-admin today; latent if that changes.

OAuth state isn't bound to a user — LinkedInOauthStates has no user_id. Largely mitigated by the callback requiring AdminUser, and it matches the existing LinearOauthStates pattern, so I'd leave it.

ON CONFLICT (user_id) vs the unique index on external_linkedin_id. A second admin connecting the same LinkedIn account misses the conflict target and hits a raw unique-violation error. Single-admin, cosmetic.

---

What I liked

The workflow reasoning is genuinely careful and the comments explain why, which is why this was reviewable at all after three months: continue-on-error on the publish steps so the commit step still runs on partial failure, ref: main instead of the triggering SHA (with the stale-linkedin_url reasoning spelled out), the App token specifically for ruleset bypass and downstream workflow triggering, and chaining off Fly Deploy so the linked page is live before the post exists. The race guard parsing frontmatter authoritatively rather than substring-scanning for linkedin_url: is the correct instinct.

---

Verified

Branch is mergeable/clean and 1 behind main; full CI green on the pre-fix commit. My change is workflow-YAML only — no Rust touched, so the existing green still stands for the code. YAML re-validated and the shell logic simulated.

Recommendation: merge, once you've made the cutoff-date call above.

[byte-the-bot]

Heads up on the Lint failure now showing on this PR — it isn't from this branch.

It fires in server/src/http_server/pages/projects.rs:123, which this PR doesn't touch and which is byte-for-byte identical on main. I reproduced it on a clean checkout of main with clippy 0.1.98: stable floated to 1.98 on 2026-08-18 and started enforcing result_large_err on the axum handler signature there. main hasn't run Rust CI since 2026-08-08, so the breakage has only been visible on PRs.

Opened #422 to unblock it (one #[allow], with the reasoning for why clippy's suggested boxing isn't available under axum). Merge that first and this PR's Lint should go green without further changes here.

Everything else on this PR is green: Test stable, Test nightly, Doc, cargo-deny, review_app.