Skip to content

[Bug]: TestGetBackendWithSlowConnection intermittently observes backend still being created #28532

Description

@ck89119

Is there an existing issue for the same bug?

  • I have checked the existing issues.

Branch Name

main (observed on PR #28499, branch issue-28491-main)

Commit ID

f4280ae (workflow head)

Other Environment Information

Actual Behavior

pkg/common/morpc.TestGetBackendWithSlowConnection failed in 0.16s:

client_lock_contention_test.go:64:
  Received unexpected error:
  internal error: morpc backend is being created
client_lock_contention_test.go:65:
  Expected value not to be nil.

This was the only failing test/package reported by this job.

Expected Behavior

The test should deterministically verify that backend creation does not block getBackend, then verify successful access after backend publication, without assuming that a fixed sleep synchronizes asynchronous work.

Steps to Reproduce

Run the Ubuntu UT job above, or run the focused test in a configured MatrixOne checkout:

.agents/skills/mo-dev/scripts/mo-cgo-test -v -count=1 -timeout=120s -run '^TestGetBackendWithSlowConnection$' ./pkg/common/morpc

The observed failure is intermittent; the focused command is a reproduction target, not a locally confirmed reproducer.

Additional information

The fixture delays factory creation by 100ms. The test sleeps for 150ms before requiring a ready backend; that sleep does not establish a happens-before relationship with publication, especially under runner scheduling delays.

PR #28499 changes unary-minus functions and their tests only. The morpc test and implementation are unchanged relative to the current main branch; this suggests an independent timing flake, but a matching clean-baseline failure has not yet been reproduced. Local validation was blocked by missing cgo/libmo.dylib and rejected cross-worktree native-artifact reuse (native inputs differ). Do not treat this report as confirmed baseline reproduction.

A follow-up fix should use explicit creation/publication synchronization rather than increasing sleeps, weakening assertions, or adding retries.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

kind/bugSomething isn't workingseverity/s0Active / top priority for current sprint. Owner has committed to working on it now.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions