Service Worker. Troubleshooting

The Reteno's web push script is loaded via a Service Worker file called sw.js and placed in the site's root. The problem can occur if the site code already uses files with the same name or uses a different Service Worker.

1. Changing the name of Service Worker sw.js

Some builders (GoDaddy, Wix, etc.) place the sw.js file in the site root by default. Since the Reteno's file has the same name, errors may occur.

To avoid problems, you can rename the file and, if necessary, specify the path to it in the Reteno's script.

To do this, find the initialization function in the Reteno's script code

es("pushOn");

and add parameters to this entry in the following format:

es("pushOn", {'service-worker': {'relUrl': '/push-worker.js'} });

where the 'relUrl' parameter is the path to the file and its arbitrary name.

2. Merging Service Workers from Reteno and PWA

Sites with PWA (progressive web app) already use Service Worker, i.e., they contain a JavaScript file with a specific set of functions. To enable the ability to subscribe and send web pushes via Reteno to your site, you need to add the line at the end of the JavaScript code of your Service Worker

importScripts('https://push.reteno.com/service-worker.js');

Note

The names of functions, variables or handlers in your Service Worker and Service Worker from Reteno may be the same. In this case, conflicts leading to failures in your PWA and the Reteno's script are possible.

Below is a list of methods’ (functions’) names in the Reteno's file:

• onPushNotification
• getNotificationContent
• showNotification
• getNotificationData
• determineClickedLink
• collectActionLinks
• trackNewServiceWorkerActivation

If the names in your Service Worker and the Reteno's Service Worker match, the function located last in the code will be called. For example, if the code according to this instruction ends with the line

importScripts('https://push.reteno.com/service-worker.js');

then the functionality related to web pushes will work correctly.

3. Manifest.json Requirements for PWA Sites

Reteno's web push script does not create or manage your PWA's manifest.json — it only merges with a Service Worker that already exists on the site (see section 2 above). If you're setting up a Progressive Web App and need a manifest.json, that file is a standard part of the PWA specification and is unrelated to Reteno's script.

A couple of points that are relevant for sites combining PWA and Reteno web push:

• Fields like display and start_url affect how the installed app behaves but don't affect Reteno's push subscription itself.
• gcm_sender_id is no longer required for push notifications in Chrome — it has been replaced by VAPID keys, which Reteno's script handles automatically.

4. "None of Providers Responded with Success" Error

📘

Note

This error can appear for "phantom" subscribers — subscriptions with no stored browser-type information. Since the system can't determine which provider to target for these subscribers, sending fails for them specifically.

To clean such subscribers from your base, enable the option to automatically delete inactive tokens that have had no opens during the selected number of days.

5. WEB_PUSH_GENERAL_ERROR

GENERAL_ERROR for Web Push is a fallback result of the sender: it appears when no more specific provider reason was captured. Only the channel, the error code and a generic "General error" message are stored — the provider's HTTP code and raw response are not.

📘

Note

This error does not cause the token to be deleted automatically.

The same top-level code can hide different underlying causes, so it isn't sufficient on its own to build a table of causes or to justify bulk-removing tokens. Remove tokens only after checking a specific group of them.