Add connection monitoring and auto-reconnect to data-objectstack adapter by Copilot · Pull Request #364 · objectstack-ai/objectui

Copilot · 2026-02-03T01:05:13Z

Implements connection state monitoring, automatic reconnection, and batch operation progress tracking for @object-ui/data-objectstack. Updates console to ObjectStack Spec v0.9.0.

Changes

@object-ui/data-objectstack

Connection State Monitoring

Added 5-state connection lifecycle: disconnected → connecting → connected | reconnecting | error
Event-based subscription via onConnectionStateChange(listener)
Query methods: getConnectionState(), isConnected()

Auto-Reconnect

Exponential backoff on connection failures (delay × 2^(attempts-1))
Configurable: autoReconnect, maxReconnectAttempts, reconnectDelay
Enabled by default with 3 retry attempts

Batch Progress Events

Real-time progress tracking for bulk operations via onBatchProgress(listener)
Emits: operation type, total count, completed/failed counts, completion percentage

@object-ui/console

Updated spec compliance from v0.8.2 to v0.9.0
Dashboard and Page navigation already implemented, documentation updated

Usage

const dataSource = createObjectStackAdapter({
  baseUrl: 'https://api.example.com',
  autoReconnect: true,
  maxReconnectAttempts: 5,
  reconnectDelay: 1000
});

// Monitor connection state
dataSource.onConnectionStateChange(({ state, error }) => {
  if (state === 'error') console.error('Connection failed:', error);
  if (state === 'connected') console.log('Connected to ObjectStack');
});

// Track bulk operation progress
dataSource.onBatchProgress(({ operation, percentage, failed }) => {
  console.log(`${operation}: ${percentage.toFixed(1)}% (${failed} failed)`);
});

await dataSource.bulk('users', 'create', largeDataset);

API Changes

All changes are backward compatible. New features are opt-in via event listeners and configuration parameters.

Original prompt

数据适配器

4.1 @object-ui/data-objectstack (v0.3.1)

职责: ObjectStack 服务端数据适配器

当前状态:

✅ 完整 CRUD 操作 (find, findOne, create, update, delete)
✅ 批量操作 (bulk create/update/delete)
✅ 元数据获取 (getObjectSchema)
✅ LRU 缓存 + TTL 过期机制
✅ 全面错误处理 (6种错误类型)
与 Spec 对齐:

// ✅ 实现 @objectstack/client 的完整封装
import { createObjectStackAdapter } from '@object-ui/data-objectstack';

const dataSource = createObjectStackAdapter({
baseUrl: 'https://api.example.com',
token: 'auth-token'
});

// ✅ 查询参数转换
const result = await dataSource.find('users', {
filter: { age: { $gt: 18 } }, // ✅ ObjectQL 过滤器
sort: { createdAt: -1 }, // ✅ 排序
skip: 0,
limit: 20
});
缺口:

⏳ 连接状态监控和自动重连
⏳ 批量操作进度事件
⏳ 高级过滤器转换 (joins, subqueries)
5. 应用层

5.1 @object-ui/console (v0.1.0)

职责: ObjectStack 控制台 - 标准运行时 UI

当前状态:

⚠️ 声明支持 ObjectStack Spec v0.8.2 (需升级到 v0.9.0)
✅ 多应用支持 (App switching)
✅ 动态 UI 渲染 (Dashboard, Grid, Form)
✅ 权限感知导航
✅ 应用品牌定制 (logo, colors)
与 Spec 对齐:

// ✅ AppSchema 支持
import { App } from '@objectstack/spec/ui';

const app = App.create({
name: 'my_app',
label: 'My App',
icon: 'users',
branding: {
logo: '/logo.png',
primaryColor: '#10B981'
},
navigation: [...] // ✅ 支持 object/dashboard/page/url/group
});
缺口:

❌ 版本落后 (v0.8.2 → v0.9.0)
⏳ Dashboard 导航类型为 "planned"
⏳ Page 导航类型为 "planned"
⏳ 动态权限检查需要完善

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

vercel · 2026-02-03T01:05:19Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
objectui	Ready	Preview, Comment	Feb 3, 2026 1:17am
objectui-components	Ready	Preview, Comment	Feb 3, 2026 1:17am
objectui-crm-app	Error		Feb 3, 2026 1:17am

…o data-objectstack Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>

Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>

Copilot

Pull request overview

This PR adds connection state monitoring, automatic reconnection with exponential backoff, and batch operation progress tracking to the @object-ui/data-objectstack adapter. It also updates the console application's documented spec compliance from v0.8.2 to v0.9.0.

Changes:

Implements a 5-state connection lifecycle (disconnected → connecting → connected/reconnecting/error) with event-based subscriptions
Adds auto-reconnect functionality with exponential backoff (default: 3 attempts, starting at 1s delay)
Provides real-time progress events for bulk operations (create/update/delete)
Updates console to reflect ObjectStack Spec v0.9.0 support (dashboard and page navigation were already implemented)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
packages/data-objectstack/src/index.ts	Adds connection state management, auto-reconnect logic, and batch progress tracking to the adapter
packages/data-objectstack/src/connection.test.ts	New test file with basic tests for connection monitoring and event subscription
packages/data-objectstack/README.md	Documents new connection monitoring, auto-reconnect, and batch progress features
apps/console/src/tests/SpecCompliance.test.tsx	Updates spec version reference from v0.8.2 to v0.9.0
apps/console/README.md	Updates documented spec compliance and marks dashboard/page navigation as implemented

Copilot · 2026-02-03T01:23:54Z

+        this.reconnectAttempts = 0;
+        this.setConnectionState('connected');


The reconnect counter is not reset properly when manual connect() calls succeed after previous failures. If a user explicitly calls connect() after failed auto-reconnect attempts, the reconnectAttempts counter is reset to 0 at line 127. However, if subsequent connection failures occur, the counter starts from 0 again, which may not reflect the true number of consecutive failures if the connection is unstable.

This may be intentional behavior (resetting on successful connection), but it's not documented. Consider clarifying the expected behavior: should the counter track consecutive failures across manual reconnects, or should it reset on any successful connection?

Copilot · 2026-02-03T01:23:54Z

+          completed = ids.length;
+          failed = total - completed;
+          emitProgress();


The batch progress tracking for the 'delete' operation has a logic error. At line 377, failed is calculated as total - completed, but this doesn't account for items that were missing IDs. Items missing IDs are already counted as failures at line 368, but then at line 377, the calculation would incorrectly mark additional items as failed.

If some items have IDs and some don't, ids.length would be less than total, and failed = total - ids.length would double-count the failures. The correct approach would be to set failed = total - ids.length before the error throw at line 368, and after successful deletion, set failed = 0.

Copilot · 2026-02-03T01:23:55Z

+              completed = updated.length;
+              failed = total - completed;
+              emitProgress();
+              return updated;
            } catch {
              // If updateMany is not supported, fall back to individual updates
              // Silently fallback without logging


The batch progress tracking for 'update' operations with updateMany has the same issue as create operations - it assumes all-or-nothing behavior. At lines 391-393, the code sets completed = updated.length and failed = total - completed, but if updateMany can partially succeed, this won't accurately reflect the actual success/failure breakdown.

Additionally, if updateMany throws an exception after partial success, the progress won't reflect the partial completion before the error.

Suggested change

completed = updated.length;

failed = total - completed;

emitProgress();

return updated;

} catch {

// If updateMany is not supported, fall back to individual updates

// Silently fallback without logging

// Treat returned items as successfully updated records

completed = updated.length;

failed = total - completed;

emitProgress();

return updated;

} catch (error: unknown) {

// If updateMany reports a bulk error with partial success, reflect that in progress

const bulkError = error as {

successCount?: number;

failureCount?: number;

};

if (

typeof bulkError?.successCount === 'number' ||

typeof bulkError?.failureCount === 'number'

) {

const successCount =

typeof bulkError.successCount === 'number'

? bulkError.successCount

: undefined;

const failureCount =

typeof bulkError.failureCount === 'number'

? bulkError.failureCount

: (typeof successCount === 'number' ? total - successCount : undefined);

if (typeof successCount === 'number') {

completed = successCount;

}

if (typeof failureCount === 'number') {

failed = failureCount;

}

emitProgress();

// Re-throw so callers can inspect the bulk error details

throw error;

}

// If updateMany is not supported or failed without partial counts,

// fall back to individual updates. Silently fallback without logging.

Copilot · 2026-02-03T01:23:55Z

+describe('Connection State Monitoring', () => {
+  let adapter: ObjectStackAdapter;
+
+  beforeEach(() => {
+    adapter = new ObjectStackAdapter({
+      baseUrl: 'http://localhost:3000',
+      autoReconnect: false, // Disable auto-reconnect for testing
+    });
+  });
+
+  it('should initialize with disconnected state', () => {
+    expect(adapter.getConnectionState()).toBe('disconnected');
+    expect(adapter.isConnected()).toBe(false);
+  });
+
+  it('should allow subscribing to connection state changes', () => {
+    const listener = vi.fn();
+    const unsubscribe = adapter.onConnectionStateChange(listener);
+
+    expect(typeof unsubscribe).toBe('function');
+    expect(listener).not.toHaveBeenCalled();
+
+    // Cleanup
+    unsubscribe();
+  });
+
+  it('should allow subscribing to batch progress events', () => {
+    const listener = vi.fn();
+    const unsubscribe = adapter.onBatchProgress(listener);
+
+    expect(typeof unsubscribe).toBe('function');
+    expect(listener).not.toHaveBeenCalled();
+
+    // Cleanup
+    unsubscribe();
+  });
+
+  it('should unsubscribe connection state listener', () => {
+    const listener = vi.fn();
+    const unsubscribe = adapter.onConnectionStateChange(listener);
+
+    // Unsubscribe
+    unsubscribe();
+
+    // Listener should not be called after unsubscribe
+    // (We can't easily test this without triggering a connection state change)
+  });
+
+  it('should unsubscribe batch progress listener', () => {
+    const listener = vi.fn();
+    const unsubscribe = adapter.onBatchProgress(listener);
+
+    // Unsubscribe
+    unsubscribe();
+
+    // Listener should not be called after unsubscribe
+  });
+
+  it('should support auto-reconnect configuration', () => {
+    const adapterWithReconnect = new ObjectStackAdapter({
+      baseUrl: 'http://localhost:3000',
+      autoReconnect: true,
+      maxReconnectAttempts: 5,
+      reconnectDelay: 2000,
+    });
+
+    expect(adapterWithReconnect.getConnectionState()).toBe('disconnected');
+  });
+});
+
+describe('Batch Progress Events', () => {
+  let adapter: ObjectStackAdapter;
+
+  beforeEach(() => {
+    adapter = new ObjectStackAdapter({
+      baseUrl: 'http://localhost:3000',
+    });
+  });
+
+  it('should allow subscribing to batch progress', () => {
+    const listener = vi.fn();
+    const unsubscribe = adapter.onBatchProgress(listener);
+
+    expect(typeof unsubscribe).toBe('function');
+
+    // Cleanup
+    unsubscribe();
+  });
+});


Test coverage is insufficient for the new connection state and batch progress features. The tests only verify that:

Listeners can be subscribed/unsubscribed

Initial state is 'disconnected'

Configuration is accepted

The tests do not verify:

That connection state actually changes through the lifecycle (disconnected → connecting → connected)

That listeners are actually called when state changes occur

That auto-reconnect attempts are made on connection failure

That exponential backoff delays are applied correctly

That batch progress events are emitted during bulk operations

That the reconnect counter is reset on successful connection

Edge cases like maximum reconnect attempts being reached

Consider adding integration tests that mock the ObjectStackClient to test the full connection lifecycle and verify that events are emitted correctly.

Copilot · 2026-02-03T01:23:55Z

+   * Check if the adapter is currently connected
+   */
+  isConnected(): boolean {
+    return this.connected && this.connectionState === 'connected';


The isConnected() method checks both this.connected and this.connectionState === 'connected', which could lead to inconsistency. If these two state variables become out of sync, the method behavior may be unpredictable.

For example, if an error occurs after setting this.connected = true but before emitting the 'connected' state event, or if the connection state is set to 'reconnecting' while this.connected is still true, the two conditions could contradict each other.

Consider:

Using only connectionState as the source of truth and deriving connection status from it

Or, ensuring that this.connected is always updated atomically with this.connectionState

Adding assertions or validation to ensure these two states remain consistent

Suggested change

return this.connected && this.connectionState === 'connected';

return this.connectionState === 'connected';

Copilot · 2026-02-03T01:23:56Z

+        if (this.autoReconnect && this.reconnectAttempts < this.maxReconnectAttempts) {
+          await this.attemptReconnect();
+        } else {
+          throw connectionError;
+        }


The auto-reconnect logic contains a potential infinite recursion issue. When attemptReconnect() calls connect(), if connect() fails and autoReconnect is enabled with remaining attempts, it will call attemptReconnect() again. However, the reconnectAttempts counter is incremented at the start of attemptReconnect(), so if the maximum is reached during a reconnect attempt, connect() will throw an error without checking the counter again.

The issue is that if connect() throws after exhausting retries, the error propagates up through the recursion chain. However, there's no clear termination path documented, and the error thrown from line 143 may not be what callers expect during a reconnection attempt.

Consider restructuring to use a while loop instead of recursion to make the termination conditions more explicit and avoid potential stack overflow with many retry attempts.

Copilot · 2026-02-03T01:23:56Z

    if (!this.connected) {
+      this.setConnectionState('connecting');
+
      try {
        await this.client.connect();
        this.connected = true;
+        this.reconnectAttempts = 0;
+        this.setConnectionState('connected');
      } catch (error: unknown) {
        const errorMessage = error instanceof Error ? error.message : 'Failed to connect to ObjectStack server';
-        throw new ConnectionError(
+        const connectionError = new ConnectionError(
          errorMessage,
          undefined,
          { originalError: error }
        );
+
+        this.setConnectionState('error', connectionError);
+
+        // Attempt auto-reconnect if enabled
+        if (this.autoReconnect && this.reconnectAttempts < this.maxReconnectAttempts) {
+          await this.attemptReconnect();
+        } else {
+          throw connectionError;
+        }
      }
    }
  }


There's a potential race condition when connect() is called multiple times concurrently. The check at line 121 if (!this.connected) is not atomic with the connection attempt. If two async calls to connect() happen simultaneously, both could pass the check and attempt to connect, resulting in:

Duplicate connection attempts to the underlying client

Conflicting connection state updates

Multiple state change events being fired

Consider adding a connection lock or checking if a connection is already in progress (e.g., checking for connectionState === 'connecting').

Copilot · 2026-02-03T01:23:56Z

+    this.reconnectAttempts++;
+    this.setConnectionState('reconnecting');
+
+    // Exponential backoff: delay * 2^(attempts-1)
+    const delay = this.reconnectDelay * Math.pow(2, this.reconnectAttempts - 1);
+
+    await new Promise(resolve => setTimeout(resolve, delay));
+
+    this.connected = false;
+    await this.connect();


The attemptReconnect() method uses recursion to retry connections, which could lead to a deep call stack if maxReconnectAttempts is set to a high value. While the default is 3, users can configure this to be higher (e.g., 10 or more), which could cause stack overflow issues in JavaScript environments with limited stack depth.

Consider refactoring to use an iterative approach (while loop) instead of recursion.

Suggested change

this.reconnectAttempts++;

this.setConnectionState('reconnecting');

// Exponential backoff: delay * 2^(attempts-1)

const delay = this.reconnectDelay * Math.pow(2, this.reconnectAttempts - 1);

await new Promise(resolve => setTimeout(resolve, delay));

this.connected = false;

await this.connect();

let lastError: unknown = undefined;

while (this.autoReconnect && this.reconnectAttempts < this.maxReconnectAttempts) {

this.reconnectAttempts++;

this.setConnectionState('reconnecting');

// Exponential backoff: delay * 2^(attempts-1)

const delay = this.reconnectDelay * Math.pow(2, this.reconnectAttempts - 1);

await new Promise(resolve => setTimeout(resolve, delay));

this.connected = false;

try {

await this.client.connect();

this.connected = true;

this.reconnectAttempts = 0;

this.setConnectionState('connected');

return;

} catch (error: unknown) {

lastError = error;

// Loop will continue if we still have attempts left

}

}

const errorMessage =

lastError instanceof Error ? lastError.message : 'Failed to reconnect to ObjectStack server';

const connectionError = new ConnectionError(

errorMessage,

undefined,

{ originalError: lastError }

);

this.setConnectionState('error', connectionError);

throw connectionError;

Copilot · 2026-02-03T01:23:57Z

+          completed = created.length;
+          failed = total - completed;
+          emitProgress();
+          return created;


The batch progress tracking for the 'create' operation assumes all items succeed or none do. At line 353, completed is set to created.length, and at line 354, failed is calculated as total - completed. However, if the underlying createMany partially succeeds (creates some records but fails others), this logic won't accurately reflect which items failed.

The current implementation doesn't handle partial failures in batch create operations. If createMany can partially succeed, the progress tracking will be inaccurate. Consider checking if the ObjectStack client's createMany method provides information about partial failures, or document that progress tracking assumes all-or-nothing behavior for create operations.

Copilot · 2026-02-03T01:23:57Z

+  private connectionStateListeners: ConnectionStateListener[] = [];
+  private batchProgressListeners: BatchProgressListener[] = [];


The event listener arrays (connectionStateListeners and batchProgressListeners) could potentially lead to memory leaks if listeners are not properly unsubscribed. While the methods return unsubscribe functions, there's no built-in mechanism to warn users or automatically clean up listeners.

Consider:

Adding a warning if the listener count exceeds a reasonable threshold (e.g., 10-20 listeners), which might indicate a leak

Documenting the importance of calling the unsubscribe function in component unmount/cleanup

Adding a method to remove all listeners (e.g., removeAllListeners()) for cleanup scenarios

This is especially important for React components that might re-render frequently and re-subscribe without proper cleanup.

Initial plan

1d72855

Copilot AI assigned Copilot and hotlong Feb 3, 2026

Copilot started work on behalf of hotlong February 3, 2026 01:05 View session

vercel Bot deployed to Preview – objectui-components February 3, 2026 01:06 View deployment

Copilot AI and others added 2 commits February 3, 2026 01:09

Add connection state monitoring, auto-reconnect, and batch progress t…

a5d8170

…o data-objectstack Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>

Update data-objectstack documentation and add connection tests

28fdaa2

Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>

vercel Bot had a problem deploying to Preview – objectui-crm-app February 3, 2026 01:10 Failure

vercel Bot deployed to Preview – objectui-components February 3, 2026 01:14 View deployment

Copilot AI changed the title ~~[WIP] Add connection status monitoring and auto-reconnect feature~~ Add connection monitoring and auto-reconnect to data-objectstack adapter Feb 3, 2026

Copilot AI requested a review from hotlong February 3, 2026 01:15

Copilot finished work on behalf of hotlong February 3, 2026 01:15

hotlong marked this pull request as ready for review February 3, 2026 01:16

Copilot AI review requested due to automatic review settings February 3, 2026 01:16

Copilot started reviewing on behalf of hotlong February 3, 2026 01:17 View session

hotlong merged commit 6ba688d into main Feb 3, 2026
6 of 8 checks passed

vercel Bot deployed to Preview – objectui February 3, 2026 01:17 View deployment

Copilot AI reviewed Feb 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add connection monitoring and auto-reconnect to data-objectstack adapter#364

Add connection monitoring and auto-reconnect to data-objectstack adapter#364
hotlong merged 3 commits intomainfrom
copilot/add-connection-status-monitoring

Copilot AI commented Feb 3, 2026 •

edited

Loading

Uh oh!

vercel Bot commented Feb 3, 2026 •

edited

Loading

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Copilot AI Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		this.reconnectAttempts = 0;
		this.setConnectionState('connected');

-              completed = updated.length;
-              failed = total - completed;
-              emitProgress();
-              return updated;
-            } catch {
-              // If updateMany is not supported, fall back to individual updates
-              // Silently fallback without logging
+              // Treat returned items as successfully updated records
+              completed = updated.length;
+              failed = total - completed;
+              emitProgress();
+              return updated;
+            } catch (error: unknown) {
+              // If updateMany reports a bulk error with partial success, reflect that in progress
+              const bulkError = error as {
+                successCount?: number;
+                failureCount?: number;
+              };
+              if (
+                typeof bulkError?.successCount === 'number' ||
+                typeof bulkError?.failureCount === 'number'
+              ) {
+                const successCount =
+                  typeof bulkError.successCount === 'number'
+                    ? bulkError.successCount
+                    : undefined;
+                const failureCount =
+                  typeof bulkError.failureCount === 'number'
+                    ? bulkError.failureCount
+                    : (typeof successCount === 'number' ? total - successCount : undefined);
+                if (typeof successCount === 'number') {
+                  completed = successCount;
+                }
+                if (typeof failureCount === 'number') {
+                  failed = failureCount;
+                }
+                emitProgress();
+                // Re-throw so callers can inspect the bulk error details
+                throw error;
+              }
+              // If updateMany is not supported or failed without partial counts,
+              // fall back to individual updates. Silently fallback without logging.

	return this.connected && this.connectionState === 'connected';
	return this.connectionState === 'connected';

		private connectionStateListeners: ConnectionStateListener[] = [];
		private batchProgressListeners: BatchProgressListener[] = [];

Conversation

Copilot AI commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

@object-ui/data-objectstack

@object-ui/console

Usage

API Changes

Uh oh!

vercel Bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Feb 3, 2026 •

edited

Loading

vercel Bot commented Feb 3, 2026 •

edited

Loading