feat: added session search api

[isuniverseok-ua]

Why we need this PR?

This should close Issue #125

Added a basic session search functionality using task entities for indexing.

Describe your solution

1. Core Service:
   • Implemented session_search_service.py to handle vector similarity search.
   • Queries the tasks table using pgvector's cosine distance operator.
2. API Layer:
   • Added GET /api/v1/project/{id}/sessions/search in Python Core.
   • Added GET /sessions/search in Go API Server, proxying requests to Core.
3. Client SDK:
   • Added client.sessions.search(query=...) method to the Python SDK.

Implementation Tasks

Please ensure your pull request meets the following requirements:

• Implement session_search_service.py with vector logic
• Expose /sessions/search endpoint in Core and API
• Add search() method to Python Client SDK

Impact Areas

Which part of Acontext would this feature affect?

• Client SDK (Python)
• Client SDK (TypeScript)
• Core Service
• API Server
• Dashboard
• CLI Tool
• Documentation
• Other: Database Schema

Checklist

• Open your pull request against the dev branch.
• All tests pass in available continuous integration systems (e.g., GitHub Actions).
• Tests are added or modified as needed to cover code changes.

[slyt3]

I ran go test ./... locally and it fails after this PR due to pgvector not being enabled on the go side

the error:
ERROR: type "vector" does not exist (SQLSTATE 42704)
when GORM migrates
tasks.embedding vector(1536)

I think we need to ensure CREATE EXTENSION IF NOT EXISTS vector; that its executed before AutoMigrate in go and in go test db setup and the repo tests will pass I am pretty sure.

Good start, but please fix the Go pgvector/CI test failure and address the follow-ups noted in inline comments

[gusye1234]

Hi @isuniverseok-ua

I have a option in the sdk design, I think the session search should be able to be scoped, for example, within a user (https://docs.acontext.io/store/per-user), even can be required (since pgvector is low-effificent in large scale embedding search yet great for a small pool).

So maybe the SDK should be:

r = client.users.search_sessions(user='xxxx', query="xxx", topk=10)

or

client.sessions.search(query=..., user='xxxx')

Also, are you using any coding agent? Acontext has a AGENTS.md, which has the instructions of updating sync, async py sdk and ts sdk. If you're not using any ai coding, please use one and make sure the AGENTS.md is correctly loaded into your agent.

[isuniverseok-ua]

Hi @isuniverseok-ua

I have a option in the sdk design, I think the session search should be able to be scoped, for example, within a user (https://docs.acontext.io/store/per-user), even can be required (since pgvector is low-effificent in large scale embedding search yet great for a small pool).

So maybe the SDK should be:

r = client.users.search_sessions(user='xxxx', query="xxx", topk=10)

or

client.sessions.search(query=..., user='xxxx')

Also, are you using any coding agent? Acontext has a AGENTS.md, which has the instructions of updating sync, async py sdk and ts sdk. If you're not using any ai coding, please use one and make sure the AGENTS.md is correctly loaded into your agent.

@gusye1234 sure, will make changes to make this endpoint to be user scoped, i currently impl something close to

 r = client.sessions.search(query=..., user='xxxx')

then we want user_id to be mandatory arg in both sdk and api, if this is fine, I'll proceed with option 2 of what you suggested.
Also, will make sure that I ingest AGENTS.md while using any coding assistant

[slyt3]

I pulled the latest commits and re-ran tests. The pgvector migration issue is fixed now and go test ./... passes.

I still think we need a couple fixes before merge:

1. session_task_process_status values changed in Go (message.go) to pending/processing/completed/failed, but Core + other Go code still uses pending/running/success/failed (observing status query + tests). Can we keep this consistent? (I think revert to the old set unless we’re changing it everywhere.)

2. Session search scoping: Core SQL only filters by user_id. Can we also scope by project_id (or validate the user belongs to the project)? Otherwise it can mix/leak sessions across projects.

Also a question for @gusye1234 :
Core exposes configurable embedding dim/model now, but Go still hard-codes vector(1536) in the tasks schema. Since GORM tags can’t read config at runtime, do we want dim fixed at 1536 everywhere, or truly configurable (needs custom Go migrations)?

Sorry I missed some of this in my earlier review, the PR changed a lot across updates and I was mainly focused on the pgvector/CI failure first.

[gusye1234]

Core exposes configurable embedding dim/model now, but Go still hard-codes vector(1536) in the tasks schema. Since GORM tags can’t read config at runtime, do we want dim fixed at 1536 everywhere, or truly configurable (needs custom Go migrations)?

No hard-coeds vector dim is allowed @isuniverseok-ua @slyt3 , in Go api layer, we have a /src/server/api/go/configs/config.yaml, use this to pass a pre-filled value

Session search scoping: Core SQL only filters by user_id. Can we also scope by project_id (or validate the user belongs to the project)? Otherwise it can mix/leak sessions across projects.

hi @slyt3 , project_id is not visible to users (they only have api-key), so scoped with project_id is not feasible. But we should check the constrain that user id is bounded within this project, somewhere(maybe during the query of using user string to get the actually user id).

[isuniverseok-ua]

project_id is not visible to users (they only have api-key), so scoped with project_id is not feasible. But we should check the constrain that user id is bounded within this project, somewhere(maybe during the query of using user string to get the actually user id).

@gusye1234 so user_id would be a compulsory field, its just that we should derive project_id from context (?), like how do we check that user id is bounded within this project?, like one is ofc do a db call to validate this; or else we make user_id to be optional, like worst case we search across all users in any authenticated project

[gusye1234]

@isuniverseok-ua
project_id is derive from the api_key to Acontext.

The major point is that I think we shall have a way to limit the search scope, to make sure we search with condition, a user scope will be perfect. because now we're using pg_vector, which is not very good for large-scale searching

[isuniverseok-ua]

@isuniverseok-ua project_id is derive from the api_key to Acontext.

The major point is that I think we shall have a way to limit the search scope, to make sure we search with condition, a user scope will be perfect. because now we're using pg_vector, which is not very good for large-scale searching

@gusye1234 okay, can we do similar thing as done in src/server/api/go/internal/modules/handler/session.go i.e we use user string (email) in the request, we get project from context and we lookup whether or not user belongs to this project using GetByIdentifier and then we call our search for this user id and project id, apart from this can also create some index to embedding column to make it even faster