Language service hangs after custom provider times out #13862

Activity

1. sean-mcmanus commented on Aug 20, 2025

   

   Sean McManus (sean-mcmanus)

   on Aug 20, 2025

   Contributor

   More actions

   Hampus Adolfsson (@HampusAdolfsson) I'm not able to repro the issue. If there's a timeout, it falls back to configuration using the base configuration -- do you repro the same issue if you remove the configurationProvider so that it always uses them base c_cpp_properties.json configuration? Otherwise, can you attach a debugger to the cpptools.exe process (https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv ) and look for call stacks that appear to be doing work and or doing work but our stuck (i.e. ignoring the small threads that are just idle). Also, if you set the C_Cpp.loggingLevel to the hidden value of "8" temporarily it might show more logging.
2. Sean McManus (sean-mcmanus)

   self-assigned this

   on Aug 20, 2025
3. Sean McManus (sean-mcmanus)

   added

   Language Service

   more info neededThe issue report is not actionable in its current stateThe issue report is not actionable in its current state

   not reproingWe're not able to reproduce the issue (it's unlikely to get fixed until we find one).We're not able to reproduce the issue (it's unlikely to get fixed until we find one).

   Feature: Configuration ProviderRelated to the configurationProvider property, e.g. ms-vscode.cmake-tools, ms-vscode.makefile-tools.Related to the configurationProvider property, e.g. ms-vscode.cmake-tools, ms-vscode.makefile-tools.

   on Aug 20, 2025
4. github-project-automation

   added this to cpptoolson Aug 20, 2025
5. HampusAdolfsson commented on Aug 22, 2025

   

   Hampus Adolfsson (HampusAdolfsson)

   on Aug 22, 2025

   Author

   More actions

   Sean McManus (@sean-mcmanus) I see, it's unfortunate that it doesn't work on your end. The repro seems very timing-sensitive, but I've successfully run it on two machines so I don't think it's some machine-specific thing.

   do you repro the same issue if you remove the configurationProvider so that it always uses them base c_cpp_properties.json configuration?

   No, the base configuration works as expected.

   Here are the threads doing work:

   ------populate completion cache thread------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlAcquireSRWLockExclusive() (Unknown Source:0)
   msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t * mtx, const _timespec64 * target) Line 96 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\mutex.cpp:96)
   cpptools.exe!std::unique_lock<class std::recursive_mutex>::unique_lock<class std::recursive_mutex>(class std::recursive_mutex &) (Unknown Source:0)
   cpptools.exe!intellisense_client_manager::get_compilation_args(class msvc::canonicalized_file_path_t const &,struct get_compilation_args_options const &,class msvc::canonicalized_file_path_t *) (Unknown Source:0)
   cpptools.exe!include_auto_complete::cache::populate(class msvc::canonicalized_file_path_t const &) (Unknown Source:0)
   cpptools.exe!std::_Func_impl_no_alloc<`cpptools_context::cpptools_context'::`1'::<lambda_14_>,void,msvc::canonicalized_file_path_t &&>::_Do_call() (Unknown Source:0)
   cpptools.exe!`msvc::deque_thread<class msvc::canonicalized_file_path_t>::defer(class msvc::canonicalized_file_path_t &&)'::`2'::<lambda_1>::operator()(void) (Unknown Source:0)
   cpptools.exe!msvc::thread_manager_t::do_work(unsigned int) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------lsp_manager thread------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlAcquireSRWLockExclusive() (Unknown Source:0)
   msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t * mtx, const _timespec64 * target) Line 96 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\mutex.cpp:96)
   cpptools.exe!std::unique_lock<class std::recursive_mutex>::unique_lock<class std::recursive_mutex>(class std::recursive_mutex &) (Unknown Source:0)
   cpptools.exe!intellisense_client_manager::purge_old_clients(class std::chrono::duration<__int64,struct std::ratio<1,1> > const &,bool,bool) (Unknown Source:0)
   cpptools.exe!cpptools_context::cpptools_onIntervalTimer(void) (Unknown Source:0)
   cpptools.exe!``cpptools_context::initialize'::`74'::<lambda_4>::operator()'::`2'::<lambda_1>::operator()() (Unknown Source:0)
   cpptools.exe!`lsp_manager::deploy_task'::`2'::<lambda_1>::operator()() (Unknown Source:0)
   cpptools.exe!msvc::thread_manager_t::do_work(unsigned int) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------parse_root thread------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlAcquireSRWLockExclusive() (Unknown Source:0)
   msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t * mtx, const _timespec64 * target) Line 96 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\mutex.cpp:96)
   cpptools.exe!std::unique_lock<class std::recursive_mutex>::unique_lock<class std::recursive_mutex>(class std::recursive_mutex &) (Unknown Source:0)
   cpptools.exe!intellisense_client_manager::remove_header_clients(void) (Unknown Source:0)
   cpptools.exe!cpptools_context::parse_root(bool) (Unknown Source:0)
   cpptools.exe!std::_Func_impl_no_alloc<`cpptools_context::cpptools_context'::`1'::<lambda_11_>,void,cpptools_context::browse_engine_update_action_and_task_token &&>::_Do_call() (Unknown Source:0)
   cpptools.exe!`msvc::deque_thread<struct cpptools_context::browse_engine_update_action_and_task_token>::defer(struct cpptools_context::browse_engine_update_action_and_task_token &&)'::`2'::<lambda_1>::operator()(void) (Unknown Source:0)
   cpptools.exe!msvc::thread_manager_t::do_work(unsigned int) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------VC++ Worker Thread: 10------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlSleepConditionVariableSRW() (Unknown Source:0)
   KernelBase.dll!SleepConditionVariableSRW() (Unknown Source:0)
   cpptools.exe!_Cnd_timedwait_for_impl() (Unknown Source:0)
   cpptools.exe!std::condition_variable_any::wait_for<class std::unique_lock<struct msvc::mutex_t>,__int64,struct std::ratio<1,1000000000> >(class std::unique_lock<struct msvc::mutex_t> &,class std::chrono::duration<__int64,struct std::ratio<1,1000000000> > const &) (Unknown Source:0)
   cpptools.exe!cpptools_context::request_custom_configuration(class msvc::canonicalized_file_path_t const &,bool &,class std::function<bool (void)> const &) (Unknown Source:0)
   cpptools.exe!``intellisense_client_manager::acquire_intellisense_client'::`2'::<lambda_2>::operator()'::`4'::<lambda_2>::operator()() (Unknown Source:0)
   cpptools.exe!`intellisense_client_manager::acquire_intellisense_client'::`2'::<lambda_2>::operator()() (Unknown Source:0)
   cpptools.exe!msvc::thread_manager_t::do_work(unsigned int) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   

   The first three threads are all waiting for the same lock, which is being held by the worker thread. The worker thread seems to be waiting indefinitely for a custom configuration even though the provider has timed out.

   I also noticed that cpptools requests a custom configuration for the same file several times before it hangs, and I see multiple timeout popups in quick succession (with less than two seconds in-between):

   20250822-0729-53.5764618.mp4

   Here are the logs with logging level 8:
   https://gist.github.com/HampusAdolfsson/d0456f1698277b7d33b2c3b498ed20b2
6. Colengms commented on Aug 22, 2025

   

   Colen Garoutte-Carson (Colengms)

   on Aug 22, 2025

   Contributor

   More actions

   Hi Hampus Adolfsson (@HampusAdolfsson) .

   Those stacks look to be expected. They don't appear to show a deadlock. They show that the native component is still waiting to receive a FinishedRequestCustomConfig message from the TypeScript side, which is expected even on failure. That message is sent by a 'finally', and at a higher priority than other messages, so is always expected. Can you provide all other threads, in case there might be something else blocking our message queue? Otherwise, it seems like we should be looking at the TypeScript side to figure out why that 'finished' message is not being sent.

   The log you provided consists mostly of database population. Would it be possible to regenerate one, after database population is complete? Also, could you check the Console output (under Help -> Toggle Developer Tools), as that might show evidence of an exception being thrown in the TypeScript component.
7. HampusAdolfsson commented on Aug 25, 2025

   

   Hampus Adolfsson (HampusAdolfsson)

   on Aug 25, 2025

   Author

   More actions

   Colen Garoutte-Carson (@Colengms)

   Here are the other stacks:

   ------Main Thread------
   ntdll.dll!NtReadFile() (Unknown Source:0)
   KernelBase.dll!ReadFile() (Unknown Source:0)
   ucrtbase.dll!_read_nolock() (Unknown Source:0)
   ucrtbase.dll!_read() (Unknown Source:0)
   ucrtbase.dll!common_refill_and_read_nolock<char>() (Unknown Source:0)
   ucrtbase.dll!fgetc() (Unknown Source:0)
   [Inline Frame] msvcp140.dll!std::_Fgetc(char &) Line 75 (d:\a\_work\1\s\src\vctools\crt\github\stl\inc\__msvc_filebuf.hpp:75)
   msvcp140.dll!std::basic_filebuf<char,std::char_traits<char>>::uflow() Line 490 (d:\a\_work\1\s\src\vctools\crt\github\stl\inc\__msvc_filebuf.hpp:490)
   msvcp140.dll!std::basic_filebuf<char,std::char_traits<char>>::underflow() Line 470 (d:\a\_work\1\s\src\vctools\crt\github\stl\inc\__msvc_filebuf.hpp:470)
   cpptools.exe!std::getline<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_istream<char,struct std::char_traits<char> > &&,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,char) (Unknown Source:0)
   cpptools.exe!lsp_manager::read_message(class lsp_manager::client_message &) (Unknown Source:0)
   cpptools.exe!lsp_manager::process_messages(class std::function<void (void)> const &,class std::function<void (int)> const &,class std::function<void (struct lsp_client_info const &&)> const &) (Unknown Source:0)
   cpptools.exe!main() (Unknown Source:0)
   cpptools.exe!__scrt_common_main_seh() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------msvc::channel_manager::_loop_thread------
   ntdll.dll!NtRemoveIoCompletionEx() (Unknown Source:0)
   KernelBase.dll!GetQueuedCompletionStatusEx() (Unknown Source:0)
   cpptools.exe!uv__poll() (Unknown Source:0)
   cpptools.exe!uv_run() (Unknown Source:0)
   cpptools.exe!msvc::thread_proc() (Unknown Source:0)
   cpptools.exe!msvc::thread_t::invoker_t<void (*)(class std::shared_ptr<class msvc::loop_t>),class std::shared_ptr<class msvc::loop_t> &>::invoke(void) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------mscv::timer_queue_t::_thread--ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlSleepConditionVariableSRW() (Unknown Source:0)
   KernelBase.dll!SleepConditionVariableSRW() (Unknown Source:0)
   cpptools.exe!_Cnd_timedwait_for_impl() (Unknown Source:0)
   cpptools.exe!std::condition_variable_any::wait_for<class std::unique_lock<struct msvc::mutex_t>,__int64,struct std::ratio<1,1000000000> >(class std::unique_lock<struct msvc::mutex_t> &,class std::chrono::duration<__int64,struct std::ratio<1,1000000000> > const &) (Unknown Source:0)
   cpptools.exe!`msvc::timer_queue_t::timer_queue_t'::`2'::<lambda_1>::operator()() (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)----
   
   ------antrl_parse_routine------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlSleepConditionVariableSRW() (Unknown Source:0)
   KernelBase.dll!SleepConditionVariableSRW() (Unknown Source:0)
   [Inline Frame] msvcp140.dll!_Primitive_wait_for(_Cnd_internal_imp_t * const) Line 14 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp:14)
   [Inline Frame] msvcp140.dll!_Primitive_wait(_Cnd_internal_imp_t * const) Line 18 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp:18)
   msvcp140.dll!_Cnd_wait(_Cnd_internal_imp_t * cond, _Mtx_internal_imp_t * mtx) Line 58 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\cond.cpp:58)
   cpptools.exe!run_tag_parser(void) (Unknown Source:0)
   cpptools.exe!before_tu_wrapup(void) (Unknown Source:0)
   cpptools.exe!process_translation_unit(char const *,int,struct an_exported_template_file *) (Unknown Source:0)
   cpptools.exe!cfe_main(int,char * * const) (Unknown Source:0)
   cpptools.exe!cfe_main_exception_handler(int,char * * const) (Unknown Source:0)
   cpptools.exe!antlr_parse_routine() (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------VC++ Thread Pool Balancer------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlSleepConditionVariableSRW() (Unknown Source:0)
   KernelBase.dll!SleepConditionVariableSRW() (Unknown Source:0)
   cpptools.exe!_Cnd_timedwait_for_impl() (Unknown Source:0)
   cpptools.exe!`msvc::thread_manager_t::internal_initialize'::`2'::<lambda_1>::operator()() (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   ------VC++ Worker Threads (all except number 10)------
   ntdll.dll!NtWaitForAlertByThreadId() (Unknown Source:0)
   ntdll.dll!RtlSleepConditionVariableSRW() (Unknown Source:0)
   KernelBase.dll!SleepConditionVariableSRW() (Unknown Source:0)
   [Inline Frame] msvcp140.dll!_Primitive_wait_for(_Cnd_internal_imp_t * const) Line 14 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp:14)
   [Inline Frame] msvcp140.dll!_Primitive_wait(_Cnd_internal_imp_t * const) Line 18 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp:18)
   msvcp140.dll!_Cnd_wait(_Cnd_internal_imp_t * cond, _Mtx_internal_imp_t * mtx) Line 58 (d:\a\_work\1\s\src\vctools\crt\github\stl\src\cond.cpp:58)
   cpptools.exe!msvc::thread_manager_t::do_work(unsigned int) (Unknown Source:0)
   cpptools.exe!msvc::thread_helper_t::thread_entry(void *) (Unknown Source:0)
   ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   
   
   ------ntdll.dll!TppWorkerThread() (3 identical threads)------
   ntdll.dll!NtWaitForWorkViaWorkerFactory() (Unknown Source:0)
   ntdll.dll!TppWorkerThread() (Unknown Source:0)
   kernel32.dll!BaseThreadInitThunk() (Unknown Source:0)
   ntdll.dll!RtlUserThreadStart() (Unknown Source:0)
   

   The log you provided consists mostly of database population. Would it be possible to regenerate one, after database population is complete?

   Let me know if I misunderstood you, but I've generated new logs where I:

   1. Open VS Code with no C files open
   2. Wait until the logs settle
   3. Clear the logs
   4. Open a .c file to trigger cpptools to update intellisense

   Here's a run where I observed the deadlock:

   https://gist.github.com/HampusAdolfsson/082a724e27e2f2006bab666626b78261

   For reference, here's a run where I did not observe it, i.e., intellisense finished configuring correctly:

   https://gist.github.com/HampusAdolfsson/8945d13d9079ae2c8e0a764468ef7b48

   They look very similar to me. However, you can see that cpptools requests a custom configuration twice and in the failed run it only receives one cpptools/finishedRequestCustomConfig.

   Also, could you check the Console output (under Help -> Toggle Developer Tools), as that might show evidence of an exception being thrown in the TypeScript component.

   Nothing out of the ordinary here as far as I can tell:

   log.ts:440  INFO Started local extension host with pid 43096.
   log.ts:440  INFO Loading development extension at d:\repos\VSCode\cpptools-config-provider\cpptools-provider
   languagesAssociations.ts:73 Overwriting extension <<copilot-instructions.md>> to now point to mime <<text/x-instructions>>
   (anonymous) @ languagesAssociations.ts:73
   localProcessExtensionHost.ts:280 Extension Host
   localProcessExtensionHost.ts:281 Debugger attached.
   log.ts:440  INFO Settings Sync: Account status changed from uninitialized to available
   log.ts:460   ERR [Extension Host] (node:43096) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
   (Use `Code --trace-deprecation ...` to show where the warning was created)
   error @ log.ts:460
   console.ts:137 [Extension Host] (node:43096) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
   (Use `Code --trace-deprecation ...` to show where the warning was created) (at file:///c:/Users/hampusad/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:198:31117)
   Ims @ console.ts:137
   console.ts:137 [Extension Host] Failed to register the Copilot Context Provider. (at console.<anonymous> (file:///c:/Users/hampusad/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:198:31117))
   log.ts:440  INFO Auto updating outdated extensions. github.copilot, github.copilot-chat
   log.ts:440  INFO [perf] Render performance baseline is 13ms
   console.ts:137 [Extension Host] Configuration Provider timed out in 2000ms. (at console.<anonymous> (file:///c:/Users/hampusad/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:198:31117))
   Ims @ console.ts:137
   log.ts:460   ERR Conflict in settings file : Ignoring terminal.integrated.fontLigatures.enabled as terminal.integrated.fontLigatures is true
   error @ log.ts:460
   console.ts:137 [Extension Host] cpptools-provider: provideConfigurations called for 1 URIs. (at console.<anonymous> (file:///c:/Users/hampusad/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:198:31117))
   console.ts:137 [Extension Host] cpptools-provider: provideConfigurations called for 1 URIs. (at console.<anonymous> (file:///c:/Users/hampusad/AppData/Local/Programs/Microsoft%20VS%20Code/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:198:31117))
   
   
8. Sean McManus (sean-mcmanus)

   assigned

   Colen Garoutte-Carson (Colengms)

   and unassigned

   Sean McManus (sean-mcmanus)

   on Aug 25, 2025
9. sean-mcmanus commented on Sep 8, 2025

   

   Sean McManus (sean-mcmanus)

   on Sep 8, 2025

   Contributor

   More actions

   Hampus Adolfsson (@HampusAdolfsson) Can you confirm that there is an info notification popup in the bottom right notification section? Does bypassing the notification fix the issue for you?
10. Sean McManus (sean-mcmanus)

    added

    fixedCheck the Milestone for the release in which the fix is or will be available.Check the Milestone for the release in which the fix is or will be available.

    and removed

    more info neededThe issue report is not actionable in its current stateThe issue report is not actionable in its current state

    on Sep 8, 2025
11. Sean McManus (sean-mcmanus)

    added the

    Bug

    issue type on Sep 8, 2025
12. Sean McManus (sean-mcmanus)

    added

    bug

    and removed

    not reproingWe're not able to reproduce the issue (it's unlikely to get fixed until we find one).We're not able to reproduce the issue (it's unlikely to get fixed until we find one).

    on Sep 8, 2025
13. Sean McManus (sean-mcmanus)

    added this to the 1.27.4 milestone on Sep 8, 2025
14. Sean McManus (sean-mcmanus)

    moved this to Pull Request in cpptoolson Sep 8, 2025
15. Colen Garoutte-Carson (Colengms)

    closed this as completedin #13909on Sep 8, 2025
16. github-project-automation

    moved this from Pull Request to Done in cpptoolson Sep 8, 2025
17. HampusAdolfsson commented on Sep 9, 2025

    

    Hampus Adolfsson (HampusAdolfsson)

    on Sep 9, 2025

    Author

    More actions

    Sean McManus (@sean-mcmanus) Yes, pressing 'Dismiss' on the notification fixes the issue.

    Thanks for the fix Colen Garoutte-Carson (@Colengms) and Sean McManus (@sean-mcmanus)!
18. github-actions

    locked and limited conversation to collaborators on Oct 24, 2025