setContext

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.

Directly sets the active LogContext for the current thread or execution scope, replacing any previously installed context without merging.

Passing an empty LogContext clears the active context entirely (equivalent to removing it from the current scope).

This is an internal API used exclusively by the logger-coroutines module, and only on JVM/Android, where it is called by dev.shivathapaa.logger.coroutines.LogContextElement's ThreadContextElement.updateThreadContext and restoreThreadContext hooks, which the coroutine dispatcher invokes automatically on each thread switch.

On every other target ThreadContextElement does not exist, so nothing can keep this holder in sync with coroutine resumption. withLogContext deliberately does not write here on those targets: doing so handed one coroutine another coroutine's context.

Do not call this from application code. Use withContext or dev.shivathapaa.logger.coroutines.withLogContext instead.