feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics#1236
feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics#1236amir-ghasemi wants to merge 26 commits intomainfrom
Conversation
✅ FOSSA Guard: Licensing (
|
✅ FOSSA Guard: Vulnerability (
|
WhiteSource Policy Violation Summary✅︎ No Blocking Whitesource Policy Violations found in solaceai/solace-agent-mesh-ui-pr-1236! |
a52ab69 to
2a19e78
Compare
enavitan
left a comment
There was a problem hiding this comment.
Thanks Amir, this looks nice.
- left a few comments related to the architectural decision
- token counting is somewhat off, i see tracker showing me 398k out of 200k - my assumption was we should not pass the limit.
- could you please fix the unit tests, these are failing for me.
================================================================================================================================= short test summary info =================================================================================================================================
FAILED tests/integration/scenarios_programmatic/test_workflow_errors.py::test_workflow_cancellation - AssertionError: Scenario workflow_cancellation_001: Unexpected state: TaskState.failed
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestGetSessionContextUsage::test_returns_zeros_for_empty_session - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestGetSessionContextUsage::test_calculates_tokens_with_events - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestGetSessionContextUsage::test_compaction_events_excluded_from_token_counts - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestGetSessionContextUsage::test_returns_zeros_when_adk_session_service_is_none - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestContextUsageModelResolution::test_uses_component_model_config_as_default - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestContextUsageModelResolution::test_explicit_model_param_overrides_component_config - fastapi.exceptions.HTTPException: 500: Failed to get context usage
FAILED tests/unit/gateway/http_sse/routers/test_sessions_context_usage.py::TestContextUsageModelResolution::test_falls_back_to_default_model_when_no_config - fastapi.exceptions.HTTPException: 500: Failed to get context usage
============================================================================================== 8 failed
Thanks
Eugene
| ``adk_session_service`` config key. This config must point at the **same** | ||
| database that the ADK agent uses (which has the ADK ``sessions`` / ``events`` | ||
| schema). It must NOT reuse the WebUI gateway's own ``session_service`` config | ||
| because that database uses a completely different schema. |
There was a problem hiding this comment.
current approach is based on the assumption all agents use same DB instance, thus adk_session_service - is one common endpoint here, my understanding is/was each agent is free to use its own DB instance, if so shouldn't we instead expose session usage/compaction via agent itself ? i.e gateway sends an evt to agent to request compaction etc?
| appropriate backend via ``create_session_service_from_config``, runs DB | ||
| migrations for SQL backends, and optionally wraps the result with | ||
| ``FilteringSessionService`` when auto-summarization is enabled. | ||
| """ |
There was a problem hiding this comment.
in one of the upcoming tasks we will auto-enable compaction out of the box, and document how to disable it in public facing docs.
| log_identifier: str = "[SessionService]", | ||
| run_db_migrations: bool = False, | ||
| migration_component=None, | ||
| ) -> BaseSessionService: |
There was a problem hiding this comment.
I understand the intent behind direct database access for manual compaction. However, I have concerns about the architectural implications of this approach.
Current Issue
This PR introduces a second code path that can modify ADK session data:
- Agent path: Uses FilteringSessionService wrapper, respects agent configuration
- Gateway path: Uses raw DatabaseSessionService, bypasses agent business logic
This creates dual ownership of the session database - both the gateway and agents can now write to the same underlying storage. This approach also requires all agents to share the same database.
Instead of direct database access, could we implement compaction as an agent-to-agent request?
Flow:
Gateway → Solace Message → Agent → Agent compacts its own session → Response → Gateway
enavitan
left a comment
There was a problem hiding this comment.
as discussed, we need auto-compaction on if we want manual compaction to take effect.
one minor nit pick below.
| session_id = data.get("session_id") | ||
| user_id = data.get("user_id") | ||
| agent_id = data.get("agent_id") | ||
| correlation_id = data.get("correlation_id") |
There was a problem hiding this comment.
there are a few duplicates here with the above if block, might make sense to extract these
| app_name=agent_name, user_id=user_id, session_id=session_id | ||
| ) | ||
| reloaded = _filter_session_by_latest_compaction( | ||
| reloaded, log_identifier=log_id |
There was a problem hiding this comment.
this is an interesting case, if I understand correctly you are filtering it second time for cases when auto-compaction is off, but if that's the case then next session load will include all events (since FilteringService is plugged on only if the auto-compaction flag is enabled)
I see 2 options here:
1- We should roll auto-compaction for everyone first then we can allow manual compaction.
2- if we want to have manual compaction capability without auto-compaction then we need to have filtering enabled (
)for those session which were subject to manual compaction
|
5de8e8b to
48c3653
Compare
…session" fallback path
c5f4374 to
9c669f3
Compare




This pull request introduces a new "Context Usage Indicator" feature to the chat UI, allowing users to monitor and manually compact their session's context window usage. It adds backend API integration, new types, and a user interface component that displays token usage, provides warnings, and enables conversation compaction. Additionally, there are minor improvements to database migration configuration and a bugfix in the compaction logic.
Context Usage and Compaction Feature:
ContextUsageIndicatorcomponent to the chat interface, displaying current token usage, warnings as usage increases, and a button to manually compact the conversation when usage is high. This component is shown next to the chat input area. [1] [2] [3] [4]getSessionContextUsageandcompactSessionfor fetching context usage and performing manual compaction, respectively. [1] [2]context-usage.tsand re-exported them for use across the frontend. [1] [2]Backend and Migration Improvements:
alembic_version_adk) for database migrations, ensuring proper version tracking in the ADK module. [1] [2]Bugfixes: