Skip to content

Commit d7560de

Browse files
hasparushasparus
authored
guess a fix to Conf 2025 post-sync build failure (#2127)
* Guess a fix * Empty link is not external
1 parent 11734a6 commit d7560de

3 files changed

Lines changed: 32 additions & 29 deletions

File tree

‎scripts/sync-sched/schedule-2025.json‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2467,7 +2467,7 @@
24672467
"event_end": "2025-09-09 11:25",
24682468
"event_type": "Developer Experience",
24692469
"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.",
2470-
"goers": "13",
2470+
"goers": "12",
24712471
"seats": "0",
24722472
"invite_only": "N",
24732473
"venue": "IJzaal - 5th Floor",
@@ -2513,7 +2513,7 @@
25132513
"event_end": "2025-09-09 12:15",
25142514
"event_type": "Unconference",
25152515
"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.",
2516-
"goers": "0",
2516+
"goers": "1",
25172517
"seats": "0",
25182518
"invite_only": "N",
25192519
"venue": "Studio - 5th Floor",
@@ -2609,7 +2609,7 @@
26092609
"event_end": "2025-09-09 12:15",
26102610
"event_type": "GraphQL Working Group",
26112611
"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.",
2612-
"goers": "14",
2612+
"goers": "13",
26132613
"seats": "0",
26142614
"invite_only": "N",
26152615
"venue": "IJzaal - 5th Floor",

‎scripts/sync-sched/speakers.json‎

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -82,7 +82,7 @@
8282
"_years": [
8383
2025
8484
],
85-
"~syncedDetailsAt": 1756904606430
85+
"~syncedDetailsAt": 1757407371311
8686
},
8787
{
8888
"username": "adam.sayah",
@@ -212,7 +212,7 @@
212212
2023,
213213
2025
214214
],
215-
"~syncedDetailsAt": 1756904606430
215+
"~syncedDetailsAt": 1757407371311
216216
},
217217
{
218218
"username": "alex_reilly.7ldur4l",
@@ -350,7 +350,7 @@
350350
2024,
351351
2025
352352
],
353-
"~syncedDetailsAt": 1756904606430
353+
"~syncedDetailsAt": 1757407371311
354354
},
355355
{
356356
"username": "andrei.bocan",
@@ -366,7 +366,7 @@
366366
2024,
367367
2025
368368
],
369-
"~syncedDetailsAt": 1756904606430
369+
"~syncedDetailsAt": 1757407371311
370370
},
371371
{
372372
"username": "andrew.doyle1",
@@ -528,7 +528,7 @@
528528
2023,
529529
2025
530530
],
531-
"~syncedDetailsAt": 1756904606430
531+
"~syncedDetailsAt": 1757407371311
532532
},
533533
{
534534
"username": "arkenflame",
@@ -590,7 +590,7 @@
590590
2024,
591591
2025
592592
],
593-
"~syncedDetailsAt": 1756904606430
593+
"~syncedDetailsAt": 1757407371312
594594
},
595595
{
596596
"username": "benjamin154",
@@ -631,7 +631,7 @@
631631
2024,
632632
2025
633633
],
634-
"~syncedDetailsAt": 1757085026624
634+
"~syncedDetailsAt": 1757407371312
635635
},
636636
{
637637
"username": "BoD",
@@ -780,7 +780,7 @@
780780
"_years": [
781781
2025
782782
],
783-
"~syncedDetailsAt": 1757085026624
783+
"~syncedDetailsAt": 1757407371312
784784
},
785785
{
786786
"username": "christian.ernst",
@@ -820,7 +820,7 @@
820820
2024,
821821
2025
822822
],
823-
"~syncedDetailsAt": 1757085026624
823+
"~syncedDetailsAt": 1757407371312
824824
},
825825
{
826826
"username": "christian.stangier",
@@ -954,7 +954,7 @@
954954
"_years": [
955955
2025
956956
],
957-
"~syncedDetailsAt": 1757085026624
957+
"~syncedDetailsAt": 1757407462891
958958
},
959959
{
960960
"username": "donnasiqizhou",
@@ -975,7 +975,7 @@
975975
2023,
976976
2025
977977
],
978-
"~syncedDetailsAt": 1757085026625
978+
"~syncedDetailsAt": 1757407462891
979979
},
980980
{
981981
"username": "dotan1",
@@ -999,7 +999,7 @@
999999
"_years": [
10001000
2025
10011001
],
1002-
"~syncedDetailsAt": 1757085026625
1002+
"~syncedDetailsAt": 1757407462891
10031003
},
10041004
{
10051005
"username": "dotansimha",
@@ -1043,7 +1043,7 @@
10431043
"_years": [
10441044
2025
10451045
],
1046-
"~syncedDetailsAt": 1757085026624
1046+
"~syncedDetailsAt": 1757407462891
10471047
},
10481048
{
10491049
"username": "eitan15",
@@ -1132,7 +1132,7 @@
11321132
2024,
11331133
2025
11341134
],
1135-
"~syncedDetailsAt": 1757085026625
1135+
"~syncedDetailsAt": 1757407462891
11361136
},
11371137
{
11381138
"username": "ernie.turner1",
@@ -1195,7 +1195,7 @@
11951195
"_years": [
11961196
2025
11971197
],
1198-
"~syncedDetailsAt": 1757085026625
1198+
"~syncedDetailsAt": 1757407462891
11991199
},
12001200
{
12011201
"username": "fionabronwen",
@@ -1215,7 +1215,7 @@
12151215
"_years": [
12161216
2025
12171217
],
1218-
"~syncedDetailsAt": 1757085026625
1218+
"~syncedDetailsAt": 1757407462891
12191219
},
12201220
{
12211221
"username": "gabe210",
@@ -1417,7 +1417,7 @@
14171417
2024,
14181418
2025
14191419
],
1420-
"~syncedDetailsAt": 1757102430680
1420+
"~syncedDetailsAt": 1757407462891
14211421
},
14221422
{
14231423
"username": "ivan.goncharov.ua",
@@ -1531,7 +1531,7 @@
15311531
"_years": [
15321532
2025
15331533
],
1534-
"~syncedDetailsAt": 1757102430680
1534+
"~syncedDetailsAt": 1757407462891
15351535
},
15361536
{
15371537
"username": "jeff.auriemma",
@@ -1557,7 +1557,7 @@
15571557
2024,
15581558
2025
15591559
],
1560-
"~syncedDetailsAt": 1757102430680
1560+
"~syncedDetailsAt": 1757407462891
15611561
},
15621562
{
15631563
"username": "jeff737",
@@ -3197,7 +3197,7 @@
31973197
"_years": [
31983198
2025
31993199
],
3200-
"~syncedDetailsAt": 1756904606430
3200+
"~syncedDetailsAt": 1757407371312
32013201
},
32023202
{
32033203
"username": "tristan119",

‎src/app/conf/_design-system/anchor.tsx‎

Lines changed: 9 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -28,12 +28,15 @@ export const Anchor = forwardRef(function Anchor(
2828
) : (
2929
<a
3030
ref={ref}
31-
{...(!props.href.startsWith("#")
32-
? {
33-
rel: "noopener noreferrer",
34-
target: "_blank",
35-
}
36-
: {})}
31+
{
32+
// 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
33+
...(((props.href as string | undefined) || "").startsWith("#")
34+
? {
35+
rel: "noopener noreferrer",
36+
target: "_blank",
37+
}
38+
: {})
39+
}
3740
{...props}
3841
/>
3942
)

0 commit comments

Comments
 (0)