The first trace stopped at the provider pipeline.
I had confirmed the inner pipeline. fetch_data orchestrated transform_query, aextract_data, and transform_data, and one real Apple balance sheet made it all the way through Financial Modeling Prep and back as a typed FMPBalanceSheetData object. But I knew what I hadn't verified. The QueryExecutor had never run in front of me. I had read the code that handled registry resolution and provider selection. I hadn't watched either happen.
This trace closes that gap, following one request from the moment it enters OpenBB to the pipeline I already understood. The first trace showed how data moved through the provider layer. This one traces how execution reaches it.
Reopening the investigation
About a month had passed. The first thing I knew to do was reopen the environment and try the same query again. It failed immediately.
The traceback pointed into query_executor.py, credentials were being filtered before execution continued, the FMP key hadn't persisted. Working through what could actually cause it, with AI helping me interpret the traceback, brought me back to something the first trace had already taught me: environment issues are part of the investigation.
Checking which files were actually running turned up something I wasn't expecting.
Three copies of openbb_core existed on the machine: the .venv site-packages copy, which queries actually use, a global copy pytest was pulling from instead, and the repo source itself, which wasn't running at all. The .venv install had silently changed from editable to a plain static copy sometime over the month. Edit the source now, and nothing happens. What actually triggered that change, I never pinned down.
Once the key was restored and I knew which copy was real, the same Apple balance sheet came back. I had a working baseline before adding instrumentation.
Reading the orchestration layer
The first trace started by opening files and reading them top to bottom, that was the mistake. This time, I didn't repeat it, I started from a point I already trusted. fetch_data was already confirmed as the pipeline's entry point. What had to happen before fetch_data could run was what I needed to trace next.
The trail led into command_runner.py, in the application layer.
This code wasn't changing data. It was deciding what should run and handing work off, and that's what I followed: who does this hand work to next?
The chain resolved cleanly on paper. run() receives the request and resolves the command from its route. _execute_func() builds and validates the parameters next. _command() is small, its only job is to execute the resolved function and stamp the answering provider onto the result. Inside that call, maybe_coroutine runs the command function, and execution enters the three-stage pipeline I had already confirmed during the first trace.
None of that was confirmed yet. It still had to run.
Watching the chain execute
Using Cursor, I added DEBUG TRACE probes at run, _execute_func, _command, and around maybe_coroutine, placed above the existing pipeline probes. This time I knew exactly where they needed to live, in the .venv site-packages copies, the only ones that actually execute.
Then I ran one real request for Apple's balance sheet.
The trace fired in order. run logged the route. _execute_func validated the request. _command logged the provider it resolved: fmp, the piece I'd only inferred a month earlier. maybe_coroutine ran the command function. Then the pipeline from the first trace ran: transform_query built the request, aextract_data hit Financial Modeling Prep and returned one record, transform_data turned it into a typed FMPBalanceSheetData object. _command logged the provider stamped onto the result. run returned the completed OBBject.
The map, now complete
The status diagram from the first trace still had a large gray section above the provider pipeline.
After this run, it didn't.
The architecture I had inferred a month ago was now confirmed through live execution, against the Financial Modeling Prep balance sheet pipeline.
I confirmed the architecture-level execution flow through one provider implementation. I did not trace every provider OpenBB supports. This also reflects the version installed in that .venv at the time, OpenBB was mid-migration during this investigation.
Checking the trace against the documentation
After the trace was finished, I read OpenBB's architecture documentation. The execution flow was already there, the command runner, the query executor, provider resolution, the transform-extract-transform pattern.
I'd built my own model first, from the code and from watching it run. Reading the documentation first would have meant confirming someone else's understanding instead of building my own. Doing the trace first meant I had something real to compare against theirs, and they matched.
What this trace produced
The OpenBB architecture was the subject. Learning when to follow data and when to follow execution was the result.
Top comments (0)