It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().

It's common to create a context early in a test body, then do setup workunrelated to that context. By the time the context is actually used, itmay have already timed out. This was detected as test failures in#21091.The new Context() function returns a context that resets its timeout whenaccessed from new lines in the test file. The timeout does not begin untilthe context is first used (lazy initialization).This is useful for integration tests that pass contexts through manysubsystems, where each subsystem should get a fresh timeout window.Key behaviors:- Timer starts on first Done(), Deadline(), or Err() call- Value() does not trigger initialization (used for tracing/logging)- Each unique line in a _test.go file gets a fresh timeout window- Same-line access (e.g., in loops) does not reset- Expired contexts cannot be resurrectedLimitations:- Wrapping with a child context (e.g., context.WithCancel) prevents resets  since the child's methods don't call through to the parent- Storing the Done() channel prevents resets on subsequent accessesThe original fixed-timeout behavior is available via ContextFixed().