Add configurable timeout or error handling for Matomo script loading

[officinaMusci]

When using mode: 'deferred', if the Matomo server can’t be reached (e.g. network outage or a self‑hosted instance down), the <script> load never resolves and the Angular app appears stuck in “infinite loading”. I couldn’t find any documented option to set a load timeout or handle load errors, so I may be missing something.

Reproduction

1. Configure provideMatomo({ mode: 'deferred', … }) in an Angular app (v20.1.2) with ngx-matomo-client@8.0.0.
2. Point trackerUrl to an invalid or downed Matomo endpoint.
3. Serve the app and see in the console:

   Loading failed for the <script> with source “https://…/matomo.js”.
   

4. The app’s bootstrap never completes, preventing further rendering.

Expected behaviour

• Ideally there’d be a documented way to specify a timeout for the injected <script> (for example, 5 seconds).
• On timeout or load error, the library could:
  1. Stop waiting for the script.
  2. Log a warning or emit an event/observable.
  3. Allow the Angular bootstrap to finish normally.
• Even better, if script injection and its error handling were fully non‑blocking, so a Matomo load issue wouldn’t hold up app initialization.

---

Thanks for any guidance or for considering this enhancement!

[officinaMusci]

I also tried using the runOutsideAngularZone: true option, but that didn’t change the outcome.

[EmmanuelRoux]

@officinaMusci do you provide trackerUrl by using MatomoInitializerService.initializeTracker() ?

could you provide an online reproduction ?

[officinaMusci]

Hi @EmmanuelRoux,

I’ve put together a minimal reproduction on StackBlitz so you can see how I’m initializing Matomo and where the script load hangs:

https://stackblitz.com/edit/angular-gqpcqyyd?file=src%2Fmain.ts

In this demo:

• Pointing trackerUrl to a non‑existent host immediately logs the <script> load failure.
• I’ve added a console.log('test') right after matomoTracker.setUserId('test')—you’ll see that print, which means the AppInitializer isn’t blocked.
• However, in a real timeout scenario (e.g. an internal Matomo endpoint that responds slowly), the script load stays in pending indefinitely and there’s no built‑in timeout or error handling.

Unfortunately I couldn’t reproduce the full “infinite loading” effect here (my real app has additional chained providers and services), but this should illustrate that by default the injected <script> never times out. Let me know if you need any more context or if you spot something I might’ve mis‑configured.