diff --git a/scripts/sync-sched/schedule-2025.json b/scripts/sync-sched/schedule-2025.json
index 89e3ce7fc3..18f0ce4d94 100644
--- a/scripts/sync-sched/schedule-2025.json
+++ b/scripts/sync-sched/schedule-2025.json
@@ -2467,7 +2467,7 @@
     "event_end": "2025-09-09 11:25",
     "event_type": "Developer Experience",
     "description": "GraphQL error handling sucks. There, I said it.\n\nEver hunted through the errors list to figure out if a null was legit or caused by an error? If you're like me, you gave up and now treat nulls as \"maybe errored, maybe absent, maybe both.\"\n\nAnd nullability. Schema designers make anything that might fail nullable, producing partial responses when errors occur. But since anything can fail, now everything is nullable—\nand we're drowning in null checks. We recklessly cast to non-null or fall back to the empty string out of desperation. And we still don't know what's truly nullable.\n\nNo more.\n\nThis talk introduces a new, pragmatic approach, born from years of work by the Nullability WG. We propose a future where schemas reflect the true nullability of business entities, and error handling is where it belongs: in your code, not your data. Use your language's built-in tools to handle errors ergonomically; and drop the unnecessary null checks. When you read a null, it should mean one thing: the absence of data.\n\nThis isn't some distant ideal on the horizon of GraphQL's future; with just 512 bytes added to your GraphQL client, you can start adopting this today. Come see how.",
-    "goers": "13",
+    "goers": "12",
     "seats": "0",
     "invite_only": "N",
     "venue": "IJzaal - 5th Floor",
@@ -2513,7 +2513,7 @@
     "event_end": "2025-09-09 12:15",
     "event_type": "Unconference",
     "description": "Lightning Talks: <ul><li> Samuel Vazquez - MCP server demo </li><li> Andres Ortiz - GraphQL + Neo4j graph database demo </li><li> Giuseppe Abrignani - GraphQL / Enterprise data modell </li><li> Lars de Bruijn - Quantifying graphQL Schema Health </li><li> Lars de Bruijn - Trusted Documents </li></ul> <a href=\"https://github.com/graphql/graphql-wg/discussions/1815\" rel=\"noopener noreferrer\" target=\"_blank\">Lightning Talk submissions & discussion thread\n</a>\n***\n\"Unconference\" starts with U! Do you have a demo to share, an itch to scratch, lightning talk to workshop, or proposal you want to brainstorm? There's ample opportunity to bring your thoughts to the unconference table and seek or share feedback.\n\nThe unconference agenda will be created onsite - stay tuned for more info about how you can add your topics.",
-    "goers": "0",
+    "goers": "1",
     "seats": "0",
     "invite_only": "N",
     "venue": "Studio - 5th Floor",
@@ -2609,7 +2609,7 @@
     "event_end": "2025-09-09 12:15",
     "event_type": "GraphQL Working Group",
     "description": "Although the topic of namespacing has been brought up repeatedly in the GraphQL community over the last decade, there is an understandable worry that it would lead to anti-patterns in schema design. If namespacing is used as an excuse to avoid coordination between teams, this can result in a fragmented GraphQL schema that reflects current team boundaries as opposed to domain or client concerns.\n\nGraphQL Federation offers an alternative architecture: when coordination is enforced and consistency guaranteed, a large number of teams can contribute to a single, coherent GraphQL schema without the danger of stepping on each other's toes.\n\nEven with that architecture in place however, I believe there are still legitimate use cases for namespacing. In this talk, I will go over some of those use cases, and formulate a set of design principles that could guide the introduction of namespacing in GraphQL.",
-    "goers": "14",
+    "goers": "13",
     "seats": "0",
     "invite_only": "N",
     "venue": "IJzaal - 5th Floor",
diff --git a/scripts/sync-sched/speakers.json b/scripts/sync-sched/speakers.json
index f45034d5f1..5d0ec064e7 100644
--- a/scripts/sync-sched/speakers.json
+++ b/scripts/sync-sched/speakers.json
@@ -82,7 +82,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371311
     },
     {
       "username": "adam.sayah",
@@ -212,7 +212,7 @@
         2023,
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371311
     },
     {
       "username": "alex_reilly.7ldur4l",
@@ -350,7 +350,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371311
     },
     {
       "username": "andrei.bocan",
@@ -366,7 +366,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371311
     },
     {
       "username": "andrew.doyle1",
@@ -528,7 +528,7 @@
         2023,
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371311
     },
     {
       "username": "arkenflame",
@@ -590,7 +590,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371312
     },
     {
       "username": "benjamin154",
@@ -631,7 +631,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1757085026624
+      "~syncedDetailsAt": 1757407371312
     },
     {
       "username": "BoD",
@@ -780,7 +780,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026624
+      "~syncedDetailsAt": 1757407371312
     },
     {
       "username": "christian.ernst",
@@ -820,7 +820,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1757085026624
+      "~syncedDetailsAt": 1757407371312
     },
     {
       "username": "christian.stangier",
@@ -954,7 +954,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026624
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "donnasiqizhou",
@@ -975,7 +975,7 @@
         2023,
         2025
       ],
-      "~syncedDetailsAt": 1757085026625
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "dotan1",
@@ -999,7 +999,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026625
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "dotansimha",
@@ -1043,7 +1043,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026624
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "eitan15",
@@ -1132,7 +1132,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1757085026625
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "ernie.turner1",
@@ -1195,7 +1195,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026625
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "fionabronwen",
@@ -1215,7 +1215,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757085026625
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "gabe210",
@@ -1417,7 +1417,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1757102430680
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "ivan.goncharov.ua",
@@ -1531,7 +1531,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1757102430680
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "jeff.auriemma",
@@ -1557,7 +1557,7 @@
         2024,
         2025
       ],
-      "~syncedDetailsAt": 1757102430680
+      "~syncedDetailsAt": 1757407462891
     },
     {
       "username": "jeff737",
@@ -3197,7 +3197,7 @@
       "_years": [
         2025
       ],
-      "~syncedDetailsAt": 1756904606430
+      "~syncedDetailsAt": 1757407371312
     },
     {
       "username": "tristan119",
diff --git a/src/app/conf/_design-system/anchor.tsx b/src/app/conf/_design-system/anchor.tsx
index 5780c4e0e0..8845746d57 100644
--- a/src/app/conf/_design-system/anchor.tsx
+++ b/src/app/conf/_design-system/anchor.tsx
@@ -28,12 +28,15 @@ export const Anchor = forwardRef(function Anchor(
   ) : (
     <a
       ref={ref}
-      {...(!props.href.startsWith("#")
-        ? {
-            rel: "noopener noreferrer",
-            target: "_blank",
-          }
-        : {})}
+      {
+        // we want to show an error if developer doesn't pass a href, but there are cases where it may happen with data from Sched
+        ...(((props.href as string | undefined) || "").startsWith("#")
+          ? {
+              rel: "noopener noreferrer",
+              target: "_blank",
+            }
+          : {})
+      }
       {...props}
     />
   )