Skip to content

Commit edf2e19

Browse files
committed
updated code
1 parent b4cb261 commit edf2e19

2 files changed

Lines changed: 26 additions & 18 deletions

File tree

bin/testObservability/cypress/index.js

Lines changed: 11 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -202,18 +202,14 @@ Cypress.on('command:end', (command) => {
202202
});
203203

204204
/*
205-
* cy.log capture must happen at command-enqueue time AND must bypass Cypress's
206-
* test command queue. When a test body throws synchronously (e.g. a failing
207-
* chai assertion), Cypress drops every pending command in the test queue —
208-
* which means an execute-time wrapper on cy.log never runs, and even a
209-
* deferred cy.task(...) inside the SDK's afterEach is just another queued
210-
* command that won't survive the drop.
211-
*
212-
* Cypress.backend('task', ...) emits directly over the runner-to-Node
213-
* websocket (see Cypress driver), bypassing the queue entirely. Combined
214-
* with command:enqueued (which fires synchronously at the user's cy.log()
215-
* call site, before the throw), the log reaches the Node-side task handler
216-
* regardless of whether the test passes or fails.
205+
* cy.log capture must happen at command-enqueue time, not at command-execute
206+
* time. When a test body throws synchronously (e.g. a failing chai assertion),
207+
* Cypress drops every pending command in the test queue — so an execute-time
208+
* wrapper on cy.log never fires for queued logs preceding the throw.
209+
* command:enqueued fires synchronously at the user's cy.log() call site,
210+
* before the throw, so the buffer is populated regardless of pass/fail.
211+
* The buffered entries are then flushed via cy.task in the SDK's afterEach,
212+
* which Mocha runs even on test failure.
217213
*/
218214
Cypress.on('command:enqueued', (attrs) => {
219215
if (!Cypress.env('BROWSERSTACK_O11Y_LOGS')) return;
@@ -226,16 +222,14 @@ Cypress.on('command:enqueued', (attrs) => {
226222
}
227223
return [result, logItem ? logItem.toString() : ''].join(' ');
228224
}, '');
229-
Cypress.backend('task', {
225+
eventsQueue.push({
230226
task: 'test_observability_log',
231-
arg: {
227+
data: {
232228
level: 'info',
233229
message,
234230
timestamp: new Date().toISOString()
235231
},
236-
timeout: 60000
237-
}).catch(() => {
238-
/* Don't let observability failures bubble into the test */
232+
options: { log: false }
239233
});
240234
});
241235

bin/testObservability/reporter/index.js

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -628,10 +628,24 @@ class MyReporter {
628628

629629
appendTestItemLog = async (log) => {
630630
try {
631+
/*
632+
* SDK-5709: keep the hash gate on hook side (avoids attributing logs to
633+
* a stale hook pointer between hooks). Drop it on the test side. In
634+
* Cypress, EVENT_TEST_FAIL fires synchronously when a test body throws —
635+
* before afterEach runs. The SDK's internal afterEach flushes its
636+
* cy.log buffer via cy.task during afterEach, so by the time those logs
637+
* reach this listener runStatusMarkedHash[testAnalyticsId] is already
638+
* set and the log was being dropped without ever attaching a
639+
* test_run_uuid. Late LogCreated events with test_run_uuid are accepted
640+
* by the analytics backend (uploadTestSteps takes the same path with
641+
* no gate).
642+
*/
631643
if(this.current_hook && ( this.current_hook.hookAnalyticsId && !this.runStatusMarkedHash[this.current_hook.hookAnalyticsId] )) {
632644
log.hook_run_uuid = this.current_hook.hookAnalyticsId;
633645
}
634-
if(!log.hook_run_uuid && this.current_test && ( this.current_test.testAnalyticsId && !this.runStatusMarkedHash[this.current_test.testAnalyticsId] )) log.test_run_uuid = this.current_test.testAnalyticsId;
646+
if(!log.hook_run_uuid && this.current_test && this.current_test.testAnalyticsId) {
647+
log.test_run_uuid = this.current_test.testAnalyticsId;
648+
}
635649
if(log.hook_run_uuid || log.test_run_uuid) {
636650
await uploadEventData({
637651
event_type: 'LogCreated',

0 commit comments

Comments
 (0)