feat(seer): Add trigger_explorer method to SeerOperator

[alexsohn1126]

Summary

• Add SeerExplorerOperator class with trigger_explorer() method that starts or continues Explorer runs via SeerExplorerClient, checking for existing runs by category (e.g. Slack thread) and routing to continue_run() or start_run() accordingly
• Handle errors through entrypoint callbacks (on_trigger_explorer_error) and cache payload for the ExplorerOnCompletionHook via SeerOperatorExplorerCache
• Add Explorer-specific interaction types (OPERATOR_TRIGGER_EXPLORER, ENTRYPOINT_ON_TRIGGER_EXPLORER, ENTRYPOINT_CREATE_EXPLORER_CACHE_PAYLOAD, ENTRYPOINT_ON_EXPLORER_UPDATE) to SeerOperatorInteractionType for metrics instrumentation
• Widen SeerExplorerClient and collect_user_org_context to accept RpcUser in addition to User/AnonymousUser, enabling use from cross-silo contexts like Slack
• Harden SeerOperatorCompletionHook.execute(): fetch-run-status errors now log instead of aborting, add org-id mismatch guard on cache payloads, and wrap on_explorer_update calls with per-entrypoint lifecycle metrics

Refs ISWF-2022

[linear]

ISWF-2022 Add trigger_explorer method to SeerOperator

[GabeVillalobos]

Oh interesting. What is this entrypoint call doing on failure? I wonder if it needs to be contained to a task if we expect to propagate this to users reliably.

[alexsohn1126]

The entrypoint will send an error message to the thread, with a generic error message.

Maybe we should make this into a task, but at the same time, spinning up a task will require a lot more overhead, so I don't know if it's worth it 🤔

[GabeVillalobos]

There's a chance this lifecycle will never log this case, so it may be worth explicitly logging, and possibly creating a Sentry issue for this case. This seems serious if we somehow mix up organization IDs at this phase of a run.

[alexsohn1126]

Makes sense. If we find a cache with the same run_id, it better have have the same org_id, otherwise something has indeed gone wrong 😓

Added:

sentry/src/sentry/seer/entrypoints/operator.py

Lines 812 to 814 in 1c563fb

	if cache_payload.get("organization_id") != organization.id:
	lifecycle.record_failure(failure_reason="org_mismatch")
	return

[aliu39]

explorer client changes and callsites lgtm!

[aliu39]

Suggested change

	category_value=category_value,
	category_value=category_value,
	is_interactive=True,

You can add this flag as a reminder to the agent there's a user to chat with/get feedback from

Nit can also explicitly set enable_coding=False (already the default) as it's considered experimental

[alexsohn1126]

Thank you! I've changed to include both of your suggestions:

sentry/src/sentry/seer/entrypoints/operator.py

Lines 486 to 494 in 1c563fb

	client = SeerExplorerClient(
	organization=organization,
	user=user,
	category_key=category_key,
	category_value=category_value,
	on_completion_hook=SeerOperatorCompletionHook,
	is_interactive=True,
	enable_coding=False,
	)

[sentry]

Bug: In trigger_explorer, an unhandled exception after the success notification can cause a silent failure, preventing the user from receiving explorer results.
_{Severity: HIGH}

Suggested Fix

Wrap the calls to create_explorer_cache_payload() and SeerOperatorExplorerCache.set() within a try...except block. This will handle potential exceptions after the success notification has been sent, preventing the process from silently failing and ensuring state consistency. This approach aligns with the exception handling already present earlier in the method.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sentry/seer/entrypoints/operator.py#L542-L552

Potential issue: In the `trigger_explorer` method, the success callback
`on_trigger_explorer_success()` is invoked before the explorer payload is cached. If a
subsequent operation, such as `create_explorer_cache_payload()` or
`SeerOperatorExplorerCache.set()`, fails and raises an exception (e.g., due to a Redis
error), the exception is not handled. This causes the method to fail after the user has
already been notified of success. As a result, the completion hook will later find no
cache entry and will silently fail to deliver the explorer results to the user, creating
a state inconsistency and a broken user experience.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}