agentscope-ai / agentscope-ai/agentscope-java

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

Đang mở
#2,091 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
area/core/tool bug
Ngôn ngữ chính
Java
Star
5.6k
Fork
1.3k
Merge trung bình
4 ngày 12 giờ
Pull request đã merge (30 ngày)
77

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.