Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

0.7.0 fast-follow: doctor's DuckDB check, --db handling in init --cloud, and three smaller papercuts

Open
  • Is something wrong?
#775 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
cli

Research direction

Start with tokenjam/cli/cmd_doctor.py and core/db.py for the DuckDB check and storage-settings message; then trace init --cloud, commit-note, the isolation fixture in conftest.py, and the Optimize and Dashboard dollar displays. Run the named onboarding and rules tests with TJ_CONFIG exported, and check the relevant CLI and UI tests. Done means all six reported behaviors are addressed and their checks pass; consider splitting this batch into focused issues first.

Written by the indexing model from the issue text.

Description

bug

Batched follow-ups found by the 0.7.0 pre-release test. None of these gated the release. The first two ship today on 0.6.12 as well, so they are not 0.7.0 regressions, but the first one is visible on a first run and is the one worth fixing soonest.

1. tj doctor reports a red ✗ on "DuckDB writable"

✗  DuckDB writable: Cannot open database: Connection Error: Can't open a
   connection to same database file with a different configuration than
   existing connections

_check_db in tokenjam/cli/cmd_doctor.py opens a bare duckdb.connect(path) with no config=, while core/db.py already holds a connection to the same path opened with memory_limit, threads and temp_directory. DuckDB's per-path instance cache rejects the mismatch.

The existing downgrade only matches "conflicting lock" and "could not set lock", so this different error falls through to level: error. Reproduces on a fresh database, with and without --db, and identically on the published 0.6.12 wheel.

A new user running tj doctor on a healthy install sees a hard red error about their database being unwritable when it is fine. Fix is to pass the same settings, or to reuse the live connection rather than opening a second one.

2. The storage-settings fallback message contradicts itself

storage.memory_limit='2GB' / storage.threads=4 rejected by DuckDB; falling back to 2GB / 4

Same root cause as #1, same fall-through. It announces a fallback to the values it just said were rejected, which tells the reader nothing and suggests a problem that does not exist. Also pre-existing.

3. tj init --cloud ignores the global --db override

It reads config.storage.path rather than the database the --db flag selected, so tj --db X init --cloud … reports "Forwarded 0 spans, 0 sessions, 0 commits" while syncing from the default database instead. Pointing storage.path at the same file forwards correctly, so a user who never passes --db is unaffected. Worth a one-line fix for consistency with every other command that honours the flag.

4. tj commit-note has no subcommand-level --json or -v

Both are group-level options, so the working invocations are tj --json commit-note and tj -v commit-note. tj commit-note --json does not parse. The documentation now shows the working form, but the flags read more naturally on the subcommand and every neighbouring command accepts them there.

5. The test suite is not immune to an exported TJ_CONFIG

conftest.py's autouse isolation fixture redirects HOME but leaves TJ_CONFIG alone, so a developer with that variable exported in their shell gets three failures that have nothing to do with their change: test_onboard_path_branch::test_bare_onboard_sdk_choice_falls_through_to_generic and both test_rules_surface tests. They pass under env -u TJ_CONFIG.

Isolation that covers one environment variable and not the other is worse than none, because the failure looks like a real regression in onboarding. Unset TJ_CONFIG in the same fixture.

6. Dollar precision differs between two surfaces

The Optimize page renders four decimals ($0.0000 measured, $64.3235) where the Dashboard renders two ($64.32) for the same quantities. Presentation only, but the two screens sit one click apart.

🤖 Generated with Claude Code

Dominant language
Python
Stars
122
Forks
35
Avg merge
1d 18h
Merged PRs (30d)
8

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Metabuilder-Labs/tokenjam

All issues in Metabuilder-Labs/tokenjam

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.