Skip to content

fix(llm, bootloader, embeddings): declare wippy/security and surface embedding errors - #116

Open
wolfy-j wants to merge 2 commits into
masterfrom
fix/security-deps
Open

fix(llm, bootloader, embeddings): declare wippy/security and surface embedding errors#116
wolfy-j wants to merge 2 commits into
masterfrom
fix/security-deps

Conversation

@wolfy-j

@wolfy-j wolfy-j commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Found while running the docs tutorials against a runtime v0.3.40a build (strict security on by default).

wippy/llm and wippy/bootloader reference a policy group they never depend on. wippy.llm.bedrock:credential_refresher.service, wippy.llm.google.oauth2:token_refresher.service and wippy.bootloader:bootloader.service declare lifecycle.security.groups: [wippy.security:process], but neither module declared an ns.dependency on wippy/security. Any application that does not add wippy/security itself fails at boot with resolve security policy group wippy.security:process: policy group not found followed by failed to execute commit protocol. Both modules now declare dep.wippy.security (>=v0.3.0; 0.3.8 already provides the group, verified by booting a service under it).

wippy/embeddings hid the real error. generate_embedding and generate_batch_embeddings ignored the error value llm.embed returns and reported every failure as Failed to generate embedding: Unknown error (EmbedResponse has no error field, so that branch was dead). They now pass the provider message through. New wippy.embeddings:embeddings_test covers the failure path: red on the old code (Unknown error), green after.

Verification on v0.3.40a (module tests run with --set security.strict_mode=false, which the wippy.test runner needs on this runtime to discover entries):

  • llm 1208 passed before and after; bootloader 15/15; actor 21/21; agent 313/313.
  • embeddings: 0/11 before (the suite was already broken: with nothing depending on wippy/security the bootloader failed and migrations never ran) → 12/12 after.
  • Fresh app depending only on wippy/llm: wippy/security is pulled transitively, both refresher services start. With an explicit root dependency on wippy/security as well: resolves once, no conflict. Same for wippy/bootloader.
  • Existing apps (app-template, kb-central) with the worktree substituted via replacements: install and boot unchanged.
  • wippy lint --level error clean for llm, bootloader, embeddings; scripts/check_module_manifests.py passes.

Applications whose lock predates this change gain wippy/security on the next wippy run (online) or wippy update.

https://claude.ai/code/session_015FzmGSofbqiLD5HA6yZWDY

…embedding errors

wippy.llm's bedrock credential refresher and google oauth2 token
refresher, and wippy.bootloader's service, run under the
wippy.security:process policy group but neither module depended on
wippy/security, so any application that did not add it itself failed
at boot with "resolve security policy group wippy.security:process:
policy group not found". Both modules now declare the dependency.

embeddings.generate_embedding and generate_batch_embeddings ignored the
error value llm.embed returns and reported every failure as "Unknown
error". They now pass the provider error through; a test covers the
failure path.

Claude-Session: https://claude.ai/code/session_015FzmGSofbqiLD5HA6yZWDY
0.3.8 already provides the wippy.security:process group; the tighter
bound would break applications that pin security below 0.4.

Claude-Session: https://claude.ai/code/session_015FzmGSofbqiLD5HA6yZWDY
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.

2 participants