Skip to content

feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics#1236

Open
amir-ghasemi wants to merge 26 commits intomainfrom
amir/token-track
Open

feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics#1236
amir-ghasemi wants to merge 26 commits intomainfrom
amir/token-track

Conversation

@amir-ghasemi
Copy link
Copy Markdown
Collaborator

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:

  • Added ContextUsageIndicator component 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]
  • Implemented API client methods getSessionContextUsage and compactSession for fetching context usage and performing manual compaction, respectively. [1] [2]
  • Defined new types for context usage and compaction requests/responses in context-usage.ts and re-exported them for use across the frontend. [1] [2]

Backend and Migration Improvements:

  • Configured Alembic to use a custom version table name (alembic_version_adk) for database migrations, ensuring proper version tracking in the ADK module. [1] [2]

Bugfixes:

  • Fixed a bug in the compaction event logic by passing the correct agent object to the summarizer, ensuring proper summarization behavior.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 21, 2026

✅ FOSSA Guard: Licensing (SolaceLabs_solace-agent-mesh) • PASSED

Compared against main (9a2f130da2c905a7bf03b0bdd68e94af3eece230) • 0 new, 9 total (9 in base)

Scan Report | View Details in FOSSA

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 21, 2026

✅ FOSSA Guard: Vulnerability (SolaceLabs_solace-agent-mesh) • PASSED

Compared against main (9a2f130da2c905a7bf03b0bdd68e94af3eece230) • 0 new, 0 total (0 in base)

Scan Report | View Details in FOSSA

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 21, 2026

WhiteSource Policy Violation Summary

✅︎ No Blocking Whitesource Policy Violations found in solaceai/solace-agent-mesh-ui-pr-1236!

@amir-ghasemi amir-ghasemi requested a review from efunneko March 21, 2026 21:38
Copy link
Copy Markdown
Collaborator

@efunneko efunneko left a comment

Choose a reason for hiding this comment

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

Looks good!

Copy link
Copy Markdown
Contributor

@enavitan enavitan left a comment

Choose a reason for hiding this comment

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

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.
"""
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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:

  1. Agent path: Uses FilteringSessionService wrapper, respects agent configuration
  2. 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

@amir-ghasemi amir-ghasemi changed the title feat(DATAGO-113923): Real-time context usage indicator in chat with multiple metrics feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics Mar 24, 2026
@amir-ghasemi amir-ghasemi changed the title feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics Mar 25, 2026
@amir-ghasemi amir-ghasemi changed the title feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics feat(DATAGO-113923): real-time context usage indicator in chat with multiple metrics Mar 25, 2026
Copy link
Copy Markdown
Contributor

@enavitan enavitan left a comment

Choose a reason for hiding this comment

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

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")
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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 (

return FilteringSessionService(base_service)
)
for those session which were subject to manual compaction

@sonarqube-solacecloud
Copy link
Copy Markdown

Quality Gate failed Quality Gate failed

Failed conditions
53.0% Coverage on New Code (required ≥ 60%)
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE SonarQube for IDE

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.

3 participants