Error Tracking
Software fails. That’s not a flaw in Ishvana; it’s the nature of software. The question isn’t whether errors happen — they do, sometimes silently in the background, sometimes loud and in your face. The question is whether you can see them when they happen, and whether the information you’re shown is useful or useless. Most apps default to useless. A generic “something went wrong” toast, a vague modal, a “please try again” message that doesn’t tell you what to try or why it failed. You click through, nothing is fixed, the same failure happens on your next request, and you’re left guessing.
Ishvana’s answer is a subsystem called Mime — named for the silent watcher, because it watches everything and speaks only when asked — that captures every exception, every crash, every unhandled error, with structured context and a full stack trace. Mime runs in the background continuously. You don’t configure it. You don’t enable it. It’s always on. The Error Tracking panel in the Analysis workspace is where Mime’s capture becomes visible to you, structured into three tabs — Overview, Stream, and Traces — so you can answer specific diagnostic questions about what’s going wrong with your setup.
What Mime captures
Section titled “What Mime captures”Every time an exception fires inside Ishvana’s backend, Mime logs it with:
- Type. The class of exception (
ValueError,TimeoutError,ConnectionRefusedError, etc.). - Message. The exception’s message text.
- Traceback. The full Python stack trace — every function call on the way to the failure.
- Severity. Error, warning, or info, based on how the exception was raised.
- Function name. The function where the exception was caught.
- Context. A dict of arbitrary additional data captured at the error site (project ID, agent name, operation type, request payload — whatever the caller decided to attach).
- Timestamp. When the error happened.
Every logged error gets a unique signature based on its type, message, and stack trace. Errors with identical signatures get deduplicated — the second occurrence bumps the first one’s occurrence count instead of creating a new entry. This matters a lot when a bug is firing in a tight loop: you see one trace with “occurrences: 47” instead of 47 separate identical traces flooding the panel.
The three tabs
Section titled “The three tabs”Overview
Section titled “Overview”System health at a glance. Total error count, severity distribution (pie or bar chart), error rate over time, top error sources (which subsystems are producing the most errors). Time-range filter lets you scope the view to 1 hour, 6 hours, 24 hours, or 7 days.
Open Overview first when you’re doing a general health check. It answers “is anything going wrong right now?” without requiring you to scroll through individual errors.
Stream
Section titled “Stream”A chronological feed of recent errors, newest first. Each entry shows the timestamp, severity, error type, and the first line of the message. Click an entry to expand it — you get the full stack trace, the context dict, and any related errors that happened around the same time.
Stream is the view you open when you know something just went wrong and you want to see it. Write a message in Chat, get an error, open Error Tracking → Stream, and the error is right there at the top with full detail.
Traces
Section titled “Traces”Grouped view by error signature. Every unique error is its own row, with an occurrence count (how many times it’s fired) and a first-seen / last-seen timestamp pair. Click a trace to expand and see:
- The full stack trace.
- The context dict from the most recent occurrence.
- A list of every timestamp when the error fired.
- Resolution status — open, resolved, or ignored.
Resolution status is the feature that makes Traces useful over time. If you fix a bug, mark its trace resolved, and it drops out of the default view. If an error is expected and you don’t want to see it in the list anymore, mark it ignored — same effect, different intent.
The reason Traces is a separate view from Stream is that for a long-running project you’ll accumulate hundreds of individual error occurrences but only dozens of unique error signatures. Stream gives you everything in chronological order, which is good for “what just happened.” Traces gives you the deduplicated view, which is good for “what has been happening.”
Why it’s not hidden
Section titled “Why it’s not hidden”A lot of software keeps error tracking behind a developer flag. The assumption is that users don’t want to see errors because errors are scary or embarrassing. Ishvana’s position is the opposite. Hiding errors from users is how trust gets broken, not how it gets maintained. When your lore analysis silently fails and you don’t know why, you get more frustrated than you would have if the panel had shown you “timeout on LLM request, model was slow, try again or switch models.” The first case leaves you guessing. The second case tells you what to do.
Error Tracking exists because you deserve to know what’s going wrong, and because the information is useful to you — not just to the developer who might eventually look at the logs.
The kinds of errors you’ll see
Section titled “The kinds of errors you’ll see”A few common categories, with what they usually mean and how to respond:
Timeout errors. An operation took longer than its configured timeout. Most common on LLM requests with a slow model or an oversized context. Fix: wait longer (try again), reduce context, or switch to a faster model.
Context too large. The request exceeded the model’s context window. Usually shows up as a specific error from the LLM provider. Fix: enable context compression, reduce the number of documents you’re sending, or switch to a model with a larger window.
Authentication errors. An API key is missing, expired, or rejected. Most common right after you first set up a new provider. Fix: check the API key in Settings → Models.
Rate limit errors. The LLM provider is rate-limiting you. Usually transient. Fix: wait a minute and try again, or switch to a different provider for the affected operation.
Parse failures. The model returned output that couldn’t be parsed as the expected structure. Usually means the model you’re using is worse at structured output than the one you need. Fix: switch models for that operation type, or adjust the prompt in Skills.
File system errors. Disk full, permission denied, file not found. Rare but possible. Fix: check the error’s context dict for the affected path.
Unknown errors. Things that don’t match any of the above. These are the ones to report if you can’t figure them out — the full stack trace in the Traces tab is what a developer needs to diagnose the problem.
Crash dumps
Section titled “Crash dumps”Some exceptions are severe enough that Mime writes them to disk in addition to logging them in-memory. These are crash dumps — JSON files saved to data/logs/ with the full state captured at the time of the error. You don’t need to do anything with them yourself; they exist so that if you want to file a bug report, you can attach the relevant crash dump and the developers have everything they need.
Crash dumps are different from the in-memory error log in one important way: they survive restarts. The Error Tracking panel’s Stream and Traces views reset on app restart (because they’re in-memory data), but crash dumps stay on disk until you delete them. If a bug is intermittent and you want to send the developers evidence of something that happened yesterday, the crash dumps in data/logs/ are the record.
What Error Tracking is not
Section titled “What Error Tracking is not”A few things this panel deliberately doesn’t do:
- It’s not a general app log. Success operations don’t get logged here. Mime only captures exceptions and errors, not routine activity. For normal activity tracking, use Agent Overview or the Etherforce Operational Stats tab.
- It’s not a frontend error tracker. The Mime subsystem runs in the backend. Frontend JavaScript errors (Electron rendering issues, Vue component errors) don’t show up here. Those are captured separately and mostly only surface to developers, not to users.
- It’s not a real-time alerting system. There’s no push notification when an error happens. The panel shows you what’s been logged, but you have to open it to see. If you want live alerts, you’d need to check the panel periodically.
- It’s not the complete diagnostic picture. For a thorough debugging session you’d combine Error Tracking with Agent Overview (how agents are performing) and Etherforce Observability (what the LLM engine is doing). Any one of them alone is incomplete.