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

fix(rpc): a playbook run started over RPC attributes its token usage to no session

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
api, backend

Research direction

Start at the playbooks.run RPC entry and trace how usage_context.bind, sessions.get_or_create, and usage_tracker determine the session owner. Review the three listed ownership options with the usage-ledger rules, then add coverage showing the chosen behavior for an existing and unknown session without unintended session creation.

Written by the indexing model from the issue text.

Description

Summary

A playbook run started over RPC has its nodes' token spend attributed to no
session. The run itself is correct -- it reports to the named conversation, and
since the execution-context fix it also works in that session's workspace and on
its model binding -- but the usage ledger does not know which session to charge.

Where it comes from

usage_tracker reads the session to charge from a context variable:

session = usage.session_key or usage_context.session_key()

That variable is established in exactly one place, the turn path:

usage_context.bind(cid, self.sessions.get_or_create(cid).metadata.get("usage_owner", {}))

An RPC entry is not a turn, so it never enters that binding. The sibling
contexts a dispatch needs -- workdir.bind for the workspace and use_binding
for the model pair -- are now entered around the dispatch by
playbooks.run; this one was left out deliberately and is recorded here rather
than forgotten.

Why it was not closed with the others

The workspace and the binding decide what work the run does: without them a
run executed in the wrong project and on the wrong model. This one decides who
is billed for it, which is an accounting gap rather than a wrong action, and
closing it needs a decision the other two did not:

usage_context.bind takes an owner read from sessions.get_or_create(cid).
Calling that from an RPC handler would have running a playbook create a session
record as a side effect, for a session_key the caller supplied and that this
layer does not otherwise require to exist. That is a policy question about what
an RPC call may bring into being, not a detail of the run.

Options

  1. Bind with a read-only owner lookup. Attribute to session_key and read
    the owner only if the session already exists, passing None otherwise. No
    session is created; a run aimed at a session that has never spoken is charged
    to that key with no owner, which is strictly better than charged to nothing.
  2. Let the RPC entry create the session record, matching the turn path
    exactly. Simplest, and the one with the side effect worth agreeing to first.
  3. Attribute at the dispatch instead of the entry, if the graph tool is a
    better place for it than the caller -- worth considering because every future
    non-turn entry would otherwise have to remember this.

(1) looks like the smallest correct step, but the choice belongs with whoever
owns the usage ledger's rules about unknown sessions.

Reproducing

Call playbooks.run with a session_key and a playbook whose nodes reach a
model, then look at the usage record for those nodes: session_key is empty
where a turn-initiated run of the same playbook carries the conversation.

Dominant language
Python
Stars
4.1k
Forks
94
Avg merge
15h 38m
Merged PRs (30d)
400

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 EverMind-AI/Raven

All issues in EverMind-AI/Raven

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.