Skip to content

fix(backtesting): log service requirement resolution errors instead of swallowing them - #3745

Open
Herklos wants to merge 1 commit into
devfrom
cursor/backtesting-service-requirements-errors-3792
Open

Herklos wants to merge 1 commit into
devfrom
cursor/backtesting-service-requirements-errors-3792

Conversation

@Herklos

@Herklos Herklos commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

Summary

Stop silently dropping errors raised while resolving the service classes required by backtesting evaluators.

Changelog

  • OctoBotBacktesting._create_services logs requirement lookup failures with the evaluator name instead of except Exception: pass
  • Non-fatal behaviour is unchanged: backtesting still starts and the remaining services are initialized
  • Unit tests cover the logged exception on a raising requirements lookup and the no-log success path

What's new?

_create_services walks the evaluators and asks tentacles_manager_api.get_tentacle_classes_requirements which services each one needs. Any failure in that loop was swallowed, so a backtesting run could start without a service it needs and nothing was logged.

The handler now calls logger.exception with the evaluator name and keeps publish_error_if_necessary off, matching the existing service-initialization error log right below it. The exception type is not narrowed yet, since the set of expected failures is not known; that can follow once they are catalogued.

Testing

  • pytest tests/unit_tests/backtesting: the new "logs exception" test fails before the fix and passes after
  • pytest packages/backtesting/tests -n auto --dist loadfile: 78 passed
  • pytest tests/unit_tests -n auto --dist loadfile: 502 passed
  • python -m tools.extended_linter --base origin/dev: 0 violations
Open in Web Open in Cursor 

…f swallowing them

Failures from tentacles requirement lookup were silently dropped in
OctoBotBacktesting._create_services. Log them with the evaluator name
and keep the non-fatal behaviour.

Co-authored-by: herklos.dev <herklos.dev@protonmail.com>
@Herklos
Herklos requested a review from GuillaumeDSM as a code owner October 13, 2026 13:37
@Herklos Herklos self-assigned this Oct 13, 2026

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The catch stays non-fatal, and the new tests cover the logger call. The evaluator name does not reach the log line: with the second argument False, BotLogger.exception logs str(exception) and the traceback only.

Open in Web View Automation 

Sent by Cursor Automation: Review

Comment on lines +386 to +391
self.logger.exception(
e,
False,
f"Failed to resolve service requirements of {evaluator.__class__.__name__} for backtesting, "
f"its required services might not be started"
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BotLogger.exception only writes error_message via self.error when the second argument is true. With False, the logging call receives the exception object as the message, and the file format is %(message)s, so the log line is the exception text plus the traceback. The evaluator name stays on extra["exception_desc"] and does not appear.

The other logger.exception calls in this file pass True. The init failure just below uses logger.error, which does put its sentence in the log and counts it as a backtesting error.

Pass True here, or log the same sentence with logger.error, so the evaluator name is in the log.

This branch has not been deployed

No deployments
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