Skip to content

fix(prompt): start PromptCache workers lazily instead of on import#26

Open
aloktripathi1 wants to merge 1 commit into
future-agi:mainfrom
aloktripathi1:fix/prompt-cache-lazy-threads
Open

fix(prompt): start PromptCache workers lazily instead of on import#26
aloktripathi1 wants to merge 1 commit into
future-agi:mainfrom
aloktripathi1:fix/prompt-cache-lazy-threads

Conversation

@aloktripathi1

Copy link
Copy Markdown

Closes (link the cache thread issue if you filed one separately)

Importing fi.prompt (per the README's own quickstart, from fi.prompt import Prompt, PromptTemplate, ModelConfig) eagerly spawns 2 background
_RefreshWorker daemon threads via the module-level prompt_cache singleton.

These threads poll an empty queue forever, because refresh_async(), the
only thing that feeds work to them, is never called anywhere in the SDK.
get_by_name() explicitly opts out, per its own comment: "Async refresh logic
is not applied here to simplify the fallback flow." So every user importing
fi.prompt gets 2 permanently idle threads for zero benefit.

Verified with threading.active_count() before and after the README import:

  • Before fix: 2 PromptCacheWorker threads spawn immediately on current main
  • After fix: 0 threads spawn on import

Fix: _TaskManager now starts its workers lazily on the first submit() call
via double-checked locking, instead of eagerly in init. No public API
change, refresh_async() behaves exactly as before, the threads just start
on demand if and when something actually uses them.

4 new regression tests:

  • No workers exist immediately after construction
  • Workers start correctly on the first submit() call
  • Repeated _ensure_started() calls don't spawn duplicate workers
  • _shutdown() is safe to call even if nothing was ever submitted

Note: the 2 failing tests in test_annotation_queues.py
(TestAnalytics::test_get_analytics, TestExport::test_export_json) are
pre-existing on main and unrelated to this change.

PromptCache spawned 2 background _RefreshWorker daemon threads eagerly at
construction, including for the module-level singleton created at import.
But refresh_async() -- the only thing that feeds those threads -- is never
called in the SDK, so every user importing fi.prompt got 2 permanently
idle threads.

_TaskManager now starts workers lazily on first submit() via double-checked
locking. No public API change; refresh_async() works as before, threads
just start on demand.

Adds 4 regression tests covering lazy startup, on-demand worker creation,
idempotent start, and safe shutdown before any submit.
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