agentscope-ai / agentscope-ai/agentscope-java

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

Aberta
#2,091 1 comentário 0 reações 0 responsáveis Ver no GitHub
area/core/tool bug
Linguagem predominante
Java
Estrelas
5.6k
Forks
1.3k
Merge médio
4d 12h
PRs com merge (30d)
77

Descrição

## 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.

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.