#All Cloudflare Snippets are throwing errors

30 messages · Page 1 of 1 (latest)

thorn helm
#

Error 1101
Worker threw exception

there's nothing on the cf status page informing about this issue. and no one discusses it here, so I need info about why is this happening to all our snippets.

edit 1:
snippets that were previously working and we didn't even update encounter the same error too. so I assume it's not something wrong with the code.

edit 2:
using gtmetrix to see if it's reachable from other region, but no it's not. got 500 Internal Server Error

thorn helm
thorn helm
# thorn helm still got errors and it's been 7+ hours since and no mentions or anything on cf ...

What to expect:
This code is using one of the templates (Maintenance Page), modified the html a bit. We expected it to just work, but it's not, and giving errors such as the above Ray IDs. When tested inside the web editor Preview, it works, but it's throwing errors when deployed.

Snippet Rule:
All incoming requests

Code to reproduce:

// Define your customizable inputs
const statusCode = 200;
const title = "We'll Be Right Back!";
const message = "Our site is currently undergoing scheduled maintenance. We’re working hard to bring you a better experience. Thank you for your patience and understanding.";
const estimatedTime = "3 to 7 work days";

export default {
    async fetch(request) {
        // Serve the maintenance page as a response
        return new Response(generateMaintenancePage(), { status: statusCode, 
            headers: { "Content-Type": "text/html", "Retry-After": "3600", // Suggest retry after 1 hour 
            },
        });
    },
};

function generateMaintenancePage() {
  return `
// html code here
    `;
}
forest tundra
#

there was nothing wrong with Snippets backend or control plane for weeks, so the issue is specific to your code or account configuration. your code works if contact references are removed from the template.

thorn helm
# forest tundra there was nothing wrong with Snippets backend or control plane for weeks, so the...

even using default template will throw Error 1101.
this happened as per march 18th 2025, there's a snippet that's last edited 15 Feb, 2025 06:28:40 and was working perfectly before the sudden exception errors. new snippets created will throw the same error. it's not error from code, but there's just so little information shown from the user's perspective, nothing helps at all.

I provided some Ray IDs above, not sure if that'll even help debug anything from cf's side. did open a ticket since 3/19/2025, 02:26 AM GMT+7, not sure how long it'll take to get some real support there.

thorn helm
forest tundra
#

do you have any other snippet or worker triggering on the same request by any chance? anything weird in Trace output (https://developers.cloudflare.com/fundamentals/trace-request/) ?
i can't look up your rayIDs, but i can take a look if you ping me your zone or affected URL

Cloudflare Docs
Trace a request with Cloudflare Trace · Cloudflare Fundamentals docs

Cloudflare Trace (beta) follows an HTTP/S request through Cloudflare’s reverse proxy to your origin. Use this tool to understand how different Cloudflare configurations interact with an HTTP/S request for one of your hostnames. If the hostname you are testing is not proxied by Cloudflare, Cloudflare Trace will still return all the configurations...

thorn helm
forest tundra
#

are you using version management by any chance?

#

sorry, the trace output doesn't contain anything abnormal. having one snippet enabled on some kind of path that i can access and run tests against would be very helpful — unless you're using version management, in which case unfortunately this is expected on dev and staging envs currently

thorn helm
# forest tundra sorry, the trace output doesn't contain anything abnormal. having one snippet en...

does Snippets even have version management? or did you mean Snippets doesn't work as intended because workers version management is enabled somewhere?

aren't snippets supposed to run before workers? if that logic is true then does it matter what settings we're changing from the workers dashboard (other than settings to add/remove custom domains)? does that even make any sense that snippets running in front of workers but workers settings affect how snippets running (settings other than custom domains I mean) - I thought they aren't supposed to mess with each other.

Snippets can be triggered to run from some custom domains that were added from workers dashboard, okay sounds normal. but why settings other than to add/remove custom domains even affect how Snippets work? they're 2 different products tho - sounds strange that workers settings are messing with how snippets work

thorn helm
# forest tundra sorry, the trace output doesn't contain anything abnormal. having one snippet en...

having one snippet enabled on some kind of path that i can access and run tests against would be very helpful

the problem is that, even when snippets is told to run on specific subdomain (i.e., a.domain.dev), it's giving errors for other URLs (i.e. s1.domain.dev). I put my CSS on cf Pages, when enabling one of the Snippets, it prevents the Pages subdomain to load because of that error 1xxx. this will break websites that needs to access the CSS when that Snippet is enabled

thorn helm
forest tundra
#

this is weird, we will take a look

thorn helm
forest tundra
thorn helm
forest tundra
#

okay, so in the request flow Snippets execute first, and then request is passed to Workers

#

what is the worker doing that executes after snippets?

#

i've left my trace and findings in the support ticket #01433373 internally, but can confirm here that the id of the script that is throwing an exception is associated with your worker, not with your snippet

thorn helm
# forest tundra what is the worker doing that executes after snippets?

not sure, the code was a lot but definitely works normal for workers (without snippets). I haven't touched nor updated the workers code since the past 6 months because snippets has been working fine from the past few months. so not sure if there's anything wrong with the workers code,
before this happened on march 18th, snippets works just fine without changing anything from the workers code. the error suddenly popped out of nowhere, that part is weird because it affected older snippets (last edited on march 15th).

if changes was made by user then it's caused by the user, if it's not touched then how should the user know what went wrong

thorn helm
forest tundra
#

another thing that i can confirm for now is that we haven't merged anything inside Snippets edge pipeline since February, so the change on March 18th might have happened in one of the dependencies that your Worker is calling (there are a few)

#

ping me if you don't get any update from support in a few days, i'll remind them to keep looking at it

thorn helm
# forest tundra another thing that i can confirm for now is that we haven't merged anything insi...

if what you mean by deps is the imports, then looking at the code, these are the only imports in the code

import parseRange from "range-parser";
import TimeAgo from "javascript-time-ago";
import en from "javascript-time-ago/locale/en";
import "regenerator-runtime/runtime.js";
import ky from "ky";
import { Ai } from "@cloudflare/ai";
import parseUrl from "parse-url";

// @ts-ignore
import * as mime from "mime-types";
forest tundra
#

i mean other dev platform products that the worker is calling

#

there are quite a few places where things could go wrong from the interop perspective, so they will need to narrow down where exactly that exception is thrown

thorn helm
jolly grail
thorn helm
# jolly grail are you able to trigger the snippet again on some path so we can debug? you cou...

okay, here are 2 scenarios:

  1. scenario one is using the prod worker where it's integrated with r2 and kv. kv is basically unused since the past 12 months and won't be triggered since we removed the old domain acted as endpoint to that kv. but the r2 still works as expected.
  2. scenario two is using a fresly made, very simple worker script, to test if it's really the prod worker causing the problem or it's the entire Snippets (doesn't matter old or newly made snippet) causing the problem.

Snippet code used
see #1351598746487488542 message

Snippet rule used

(http.host eq "prod-workers-with-r2-snippets.0ms.dev" and starts_with(http.request.uri.path, "/workers-debug-with-snippets/")) or (http.host eq "snipdbg.0ms.dev" and starts_with(http.request.uri.path, "/workers-debug-with-snippets"))

Scenario one (prod worker with r2)
a custom domain, to see if everything works without snippets running in front of it, using the same above snippets script:

  1. https://prod-workers-with-r2.0ms.dev/
  2. https://prod-workers-with-r2.0ms.dev/workers-debug-with-snippets/
  3. https://prod-workers-with-r2.0ms.dev/workers-debug-without-snippets/

a custom domain, to see if everything works with snippets running in front of it, using the same above snippets script:

  1. https://prod-workers-with-r2-snippets.0ms.dev/
  2. https://prod-workers-with-r2-snippets.0ms.dev/workers-debug-with-snippets/
  3. https://prod-workers-with-r2-snippets.0ms.dev/workers-debug-without-snippets/

Scenario two (freshly made worker script)
a custom domain, to see if everything works with snippets running in front of the /workers-debug-with-snippets path, using the same above snippets script:

  1. https://snipdbg.0ms.dev/
  2. https://snipdbg.0ms.dev/workers-debug-with-snippets
  3. https://snipdbg.0ms.dev/workers-debug-without-snippets