agentscope-ai / agentscope-ai/agentscope-java

[Bug]: Session files are still created in workspace with RemoteFilesystem

Abierto
#2,091 1 comentario 0 reacciones 0 asignados Ver en GitHub
area/core/tool bug
Lenguaje dominante
Java
Estrellas
5.6k
Forks
1.3k
Merge medio
4 d 12 h
PR fusionados (30 d)
77

Descripción

## Describe the bug

When using AgentScope-Java 2.0 with `RemoteFilesystemSpec` and a custom `DistributedStore` implementation backed by MySQL, the session conversation data is still persisted into the local workspace directory.

I expected that when a remote filesystem is configured, session files (such as `session.json` and `*.jsonl`) would be stored through the remote filesystem backend instead of being written to the local filesystem.

However, `MemoryFlushManager -> SessionTree.flush()` still writes the session context JSONL files locally first and only mirrors them asynchronously to the remote filesystem.

This behavior makes it difficult to achieve a fully stateless deployment in Kubernetes with multiple replicas.

---

## To Reproduce

1. Configure `HarnessAgent` with a workspace and remote filesystem:

```java
builder.workspace(workspacePath);

builder.distributedStore(runtimeStore);

RemoteFilesystemSpec remoteFsSpec = new RemoteFilesystemSpec()
.addSharedPrefix(anonymousUserId)
.isolationScope(isolationScope)
.anonymousUserId(anonymousUserId);

builder.filesystem(remoteFsSpec);
```

2. Use a MySQL-backed distributed store:

```java
public class MysqlRuntimeStore implements DistributedStore {

@Override
public AgentStateStore agentStateStore() {
return new MysqlAgentStateStore(...);
}

@Override
public BaseStore baseStore() {
return JdbcStore.builder(...)
.build();
}
}
```

3. Start a conversation with `HarnessAgent`.

4. Observe the workspace directory:

```
workspacePath/
└── anonymousUserId/
├── session.json
└── .jsonl
```

The files are created locally.

---

## Expected behavior

When `RemoteFilesystemSpec` is configured, session persistence should use the remote filesystem as the primary storage backend.

Expected flow:

```
MemoryFlushManager
|
|
SessionTree.flush()
|
|
RemoteFilesystem
|
|
MySQL / remote storage
```

or there should be an option to disable local session persistence completely.

This would allow a stateless deployment:

```
Pod A
Pod B
Pod C
|
|
Remote session storage
```

without relying on local workspace files.

---

## Actual behavior

`SessionTree.flush()` writes to local files first and asynchronously mirrors to remote filesystem.

The current behavior appears to be:

```
SessionTree.flush()

|
|
+--> Local workspace file write (primary)
|
+--> Async remote filesystem mirror
```

The source code comment indicates:

> The local write is always the primary guarantee.

As a result, `session.json` and session `*.jsonl` files are always generated in the workspace directory.

---

## Error messages

No error message.

This is a behavior/design issue.

---

## Environment

* AgentScope-Java Version: 2.0.0-RC5
* Java Version: 21
* OS: Linux / Kubernetes environment

---

## Additional context

The current configuration successfully stores:

* Agent state -> MySQL (`MysqlAgentStateStore`)
* KV store -> MySQL (`JdbcStore`)
* Sandbox snapshot -> MySQL

However, conversation session data is still managed by `MemoryFlushManager` and `SessionTree`.

Relevant code path:

```
MemoryFlushManager.offloadMessages()

-> offloadToSessionTree()

-> SessionTree.append()

-> SessionTree.flush()

-> local session JSONL write
-> async remote filesystem mirror
```

For distributed multi-node deployments, it would be helpful to have:

1. A remote-first `SessionTree.flush()` mode.
2. A configuration option to disable local session persistence.
3. A pluggable `SessionStore` implementation backed by distributed storage.
4. Documentation clarifying that `RemoteFilesystemSpec` is only a mirror backend for session trees, not the primary storage.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.