ARCHIVED TRAINING / aaugustin/websockets

aaugustin__websockets-467

This is a preserved training example. Membership in the current training wave has not been verified.

Problem statement

Pong's CancelledError races with ConnectionClosed error
I upgraded to the current version of this library and I find it difficult to handle `asyncio.CancelledError` in case the pong is being cancelled due to a disconnect.

What happens in my server is that I'm waiting for pongs in one task while sending and receiving in another task. Both tasks are being waited for. The result is that in some occasions, `asyncio.CancelledError` is raised before `websockets.ConnectionClosed` and vice versa. When the `asyncio.CancelledError` is raised first, there is no context on why it has been raised.

Another problem with `asyncio.CancelledError` is that there's no way (IIRC) of finding out whether the current task has been cancelled or the task I'm waiting for has been cancelled. But this mainly is an awkward concept of asyncio and not this libraries fault. It seems one has to be extremely careful on when to cancel a task and when not to cancel a task and instead use other ways to signal cancellation (which highly depends on the task). This may clash with the design choice of this library.

TL;DR: I would prefer it if this library would raise `websockets.ConnectionClosed` in the pong's future instead of cancelling the pong.

Training membership

opd_e4b_pure_v7 opd_e4b_pure_v7b

Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.

Task and snapshot provenance

Snapshot captured 2026-11-12T17:06:59.476467+00:00 · Autoresearch-Arena/gemma-4-developer-agent

{
  "datasets": [
    "opd_e4b_pure_v7",
    "opd_e4b_pure_v7b"
  ],
  "examples": 7,
  "instance_id": "aaugustin__websockets-467",
  "problem_statement": "Pong's CancelledError races with ConnectionClosed error\nI upgraded to the current version of this library and I find it difficult to handle `asyncio.CancelledError` in case the pong is being cancelled due to a disconnect.\r\n\r\nWhat happens in my server is that I'm waiting for pongs in one task while sending and receiving in another task. Both tasks are being waited for. The result is that in some occasions, `asyncio.CancelledError` is raised before `websockets.ConnectionClosed` and vice versa. When the `asyncio.CancelledError` is raised first, there is no context on why it has been raised.\r\n\r\nAnother problem with `asyncio.CancelledError` is that there's no way (IIRC) of finding out whether the current task has been cancelled or the task I'm waiting for has been cancelled. But this mainly is an awkward concept of asyncio and not this libraries fault. It seems one has to be extremely careful on when to cancel a task and when not to cancel a task and instead use other ways to signal cancellation (which highly depends on the task). This may clash with the design choice of this library.\r\n\r\nTL;DR: I would prefer it if this library would raise `websockets.ConnectionClosed` in the pong's future instead of cancelling the pong.",
  "repo": "aaugustin/websockets",
  "source": "v2/experiments/train_data/opd_e4b_pure_v7/verified_rft_messages.jsonl",
  "source_sha256": "e37f7bd675322f3f81500b73559d60d5f602ca0537bf19f5cb06332c728c7b72"
}

{
  "captured_at": "2026-11-12T17:06:59.476467+00:00",
  "membership": "archived training",
  "membership_evidence": "Task issues extracted from preserved verified_rft_messages training examples. This is not a verified current RL wave manifest.",
  "name": "Preserved post-training task archive",
  "source": "Autoresearch-Arena/gemma-4-developer-agent",
  "source_revision": "016496de222aaafca0d4ee4c18efc63ba616f76e",
  "sources": [
    {
      "path": "v2/experiments/train_data/opd_e4b_cispo_v5/verified_rft_messages.jsonl",
      "sha256": "a43610ad0dfb6ace95375cfae09000f41afc0338cc925af870a4ade7a9b20c4c"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_hybrid_v3/verified_rft_messages.jsonl",
      "sha256": "bd326303eb127e8e5e08f03daf97bb88d79d19709d59f3f93f348bc56686a8df"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_onpolicy_v3/verified_rft_messages.jsonl",
      "sha256": "960c680e797e823a0d3a22f4b1d5ef60a72971373d703b877340b0c9126aaf68"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_pure_v6a/verified_rft_messages.jsonl",
      "sha256": "f045b7ca5b3883a1e2eaee81e1c02a4a1b53dd7b7b36e98bacb2ba5823a15148"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_pure_v6b/verified_rft_messages.jsonl",
      "sha256": "0f62460a9706eea5e1605255896f191ab00cb5706c5f1f2e1c293e9a718218dc"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_pure_v7/verified_rft_messages.jsonl",
      "sha256": "e37f7bd675322f3f81500b73559d60d5f602ca0537bf19f5cb06332c728c7b72"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_pure_v7b/verified_rft_messages.jsonl",
      "sha256": "b864bdc8695183433eef6e31cb8d33fad44ba3aded2170c1ade4ad5b2944ce23"
    },
    {
      "path": "v2/experiments/train_data/opd_e4b_self_audit_v4/verified_rft_messages.jsonl",
      "sha256": "0026023745afb8f3dc1c176dc7f7171157b4ad5a66656b524af218e8e19ceee6"
    },
    {
      "path": "v2/experiments/train_data/rft_e4b_aligned_v2/verified_rft_messages.jsonl",
      "sha256": "92a4515fee9d152b0d4c510ee3ce4caaaffe2003ba7584469f8027f174aab18c"
    },
    {
      "path": "v2/experiments/train_data/rft_v1/verified_rft_messages.jsonl",
      "sha256": "a42453ccd7ac7680b0a03865e8e7080bc8bf74c8d9d193b440c441ed46f8512b"
    },
    {
      "path": "v2/experiments/train_data/rft_v2/verified_rft_messages.jsonl",
      "sha256": "18f4b3bd7e651f83c6acab479c9475e3fa50dc652a384f309e97146983ac85ba"
    }
  ]
}