Skip to content

fix(login): default apiUrl to https://usetimebook.com#4

Merged
ktamas77 merged 1 commit intomainfrom
fix/cli-default-api-url
May 4, 2026
Merged

fix(login): default apiUrl to https://usetimebook.com#4
ktamas77 merged 1 commit intomainfrom
fix/cli-default-api-url

Conversation

@ktamas77
Copy link
Copy Markdown
Member

@ktamas77 ktamas77 commented May 4, 2026

Summary

  • Default apiUrl was https://api.usetimebook.com, but that subdomain has no DNS — DO App Platform serves both the React app and the JSON API from the bare usetimebook.com (/api/*).
  • Result: every fresh timebook login succeeds at the loopback callback, then verifyToken throws TypeError: fetch failed (DNS), the CLI bails before writeConfig. The user sees an opaque error: fetch failed and no token gets persisted.
  • Fix: change the default to https://usetimebook.com. Also wrap the fetch call in lib/api.ts to surface the underlying cause (DNS / ECONNREFUSED / cert / timeout) instead of the bare fetch failed — would have made the misconfiguration above trivial to spot.

Why

  • Confirmed via dig +short api.usetimebook.com (empty) and doctl apps spec get (only usetimebook.com + www.usetimebook.com configured on the timebook app).
  • Confirmed https://usetimebook.com/api/auth/me returns 401 from the backend as expected.

Migration

Users with a saved bad apiUrl (none expected, since login never persisted) can re-login once with TIMEBOOK_API_URL=https://usetimebook.com timebook login; the corrected value will then be stored.

Test plan

  • After 0.1.4 publishes, npx @squidcode/timebook@0.1.4 login from a fresh box completes login end-to-end and writes ~/Library/Preferences/timebook/config.json.
  • timebook whoami returns the logged-in user.

…ain exists)

The default `apiUrl` was `https://api.usetimebook.com`, but the
production deploy on DigitalOcean App Platform only has the bare
`usetimebook.com` domain — both the React app and the JSON API are
served from the same origin (`/api/*`). DNS for `api.usetimebook.com`
returns nothing, so `verifyToken` after the browser callback always
threw a bare `TypeError: fetch failed` and the CLI bailed before
writing the config — making login appear to succeed (the loopback
callback printed) but never persist a token.

Also wrap the `fetch` call in `lib/api.ts` to surface the underlying
cause (DNS, ECONNREFUSED, cert error, …) instead of the bare
`fetch failed`. This would have made the misconfiguration above
trivial to diagnose.

Users with an already-saved bad apiUrl can re-run with
`TIMEBOOK_API_URL=https://usetimebook.com timebook login` once;
the corrected value will then be persisted.
@ktamas77 ktamas77 merged commit fd5e0c9 into main May 4, 2026
0 of 3 checks passed
@github-actions github-actions Bot mentioned this pull request May 4, 2026
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