Support
Till senaste kommentaren

SL API ger gammal info sedan måndag förmiddag, 5 maj

Har fastnat på gamla tider.

https://transport.integration.sl.se/v1/sites/9304/departures
Peter

Kommentarer

  • Någon prognos på när detta är fixat...?
    Per
  • Idag igen så upphörde uppdateringarna i API:et strax efter 11.00.

    https://transport.integration.sl.se/v1/sites/9191/departures
    Per
  • Hej Per,

    När jag nu går in på länken ser jag aktuella avgångar. Är felet kvar för dig?

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Ser ut att vara cloudfront (CDN) som cachar resultaten av avgångar (och alla andra APIer). Om jag tex. gör ett anrop mot

    https://transport.integration.sl.se/v1/sites/9307/departures?transport=METRO

    Så får jag följande information tillbaka i headers:

    Content-Type: application/json; charset=UTF-8; indent="false"

    Transfer-Encoding: chunked

    Connection: keep-alive

    Date: Tue, 06 May 2025 09:30:37 GMT

    x-correlation-id: c4ecb390-2a5c-11f0-9ed3-8a5313954e64

    Content-Encoding: gzip

    Vary: Accept-Encoding

    Vary: Origin

    X-Cache: Hit from cloudfront

    Via: 1.1 269b0fad85dfd450220cf6573a2d384e.cloudfront.net (CloudFront)

    X-Amz-Cf-Pop: ARN56-P2

    X-Amz-Cf-Id: WnbxYx0Vkg7pvnNz9AGNm56ttMZVIWI__MH726GDT805sUaDeDg3FA==

    Age: 2941

    Titta speciellt på X-Cache, Date och Age, vilket visar att resultatet felaktigt cache'as och gör det oanvändbart. Helt OK att de andra API'erna frontas av ett CDN som Cloudfront, men "departures" måste gå direkt för att gå och använda.
    Kristofer
  • Hej igen Bert,

    När jag går in på länken är samtliga avgångar från tidigare idag (11-tiden). Testa att gå in nu igen och se om avgångarna fastnat för dig med.

    Mvh
    Per
  • Med hjälp av Kristoffers tips ovan gick det att lösa genom att lägga till en "?forecast=60" i anropet.
    Per
  • Per, länken du skickade

    https://transport.integration.sl.se/v1/sites/9191/departures

    Returnerar cache'ad information från "Tue, 06 May 2025 11:07:46 GMT" enligt mig och headern jag kan se via Postman (och kod). Trafiklab har satt ett CDN/Cache (AWS Cloudfront) framför API'erna som felaktigt cache'ar data från departures. I alla fall är det så jag förstår det.
    Kristofer
  • Hej Per,

    Tack för återkopplingen, det bekräftar att olika användare får olika resultat från cachen. Själv får jag nu resultat från 12:40-tiden. Cachen sak finnas för att inte överbelasta tjänsten, men cachen ska inte spara resultat i mer än 60-120 sekunder (så age-headern bör inte överstiga 60-120 i vanliga fall).

    Cachen är del av SLs API, det är inget vi kan styra. Vi återkopplar detta till SL så att de kan åtgärda felet.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Men tyvärr Per, så löser nog det bara problemet en gång. Dvs. du får en cache-miss från Cloudfront första gången en unik URL kommer in, men därefter så är det samma elände igen till dess att cache'n förnyas. Så du måste hitta på nya url'er eller query-parametrar hela tiden för att inte hamna i cachen.

    Tex. första anropet till

    https://transport.integration.sl.se/v1/sites/9191/departures?forecast=59

    Gav mig header'n:

    X-Cache: Miss from cloudfront

    Men andra försöket säger istället:

    X-Cache: Hit from cloudfront
    Age: 140

    Vilket betyder att informationen cahe'ats i 140s av Cloudfront.

    Trafiklab måste stänga av Cache för anrop till:

    https://transport.integration.sl.se/v1/sites/{{site}}/departures

    ... helt och hållet eller hålla cachen väldigt kort tid, typ 5 sekunder.
    Kristofer
  • "Cachen sak finnas för att inte överbelasta tjänsten, men cachen ska inte spara resultat i mer än 60-120 sekunder (så age-headern bör inte överstiga 60-120 i vanliga fall)."

    Förstår varför ni har en cache, men på ett API som talar om utifall ett tåg kommer om 1 minut, så kan inte cachen vara längre än så?!?! Cach-tiden måste vara kortare om API'et skall vara användbart. Annars kommer det ibland stå:

    "Linje 10 Kungsträdgården avgår om 2 minuter", fastän tåget står på perongen.
    Kristofer
  • Det verkar stämma, Kristoffer, man får hitta på nya URL:s tills detta är löst 😀
    Per
  • Det verkar som att cachen gäller ett dygn ungefär just nu.
    Peter
  • Tog lite för lång tid att vänta på en lösning så jag la på ett uuid på varje request. Då är det unikt och går runt cachen. Säkert inte det SL vill, men de bör nog se över cache-lösningen lite. Just nu går inte API:t använda utan att fula sig.

    Jag cachar saker på min sida där jag har mer kontroll och vet när jag måste hämta ny information.
    Andreas
  • Tack för tipset, har fixat mitt eget system också. Jag kör max var 30:e sekund, det räckte för att hålla gränsen på 10 000 request per månad i det gamla APIet.

    Med tankte på att problemet också drabbar skyltarna i tunnelbanan och SLs egen app så kan man ju hoppas att de hittar hit så det kan lösa problemet själva också. ;-)
    Peter
  • Blev fel där, 30 sekunder ska vara 5 minuter! Sen beräknar jag lokalt tiderna var 30:e sekund utifrån den infon.
    Peter
  • Haha, ja vi vet ju vad problemet är och hur det skall fixas, så håller med dig Peter, vore bra om dom hittade hit.

    Jag har läst på dokumentationen för AWS CloudFront och tror att fixen skulle vara väldigt enkel att implementera med ett kort skript som ändrar Time To Live, TTL, till 5 sekunder (gärna kortare för mig) för alla anrop som matchar mönstret:

    https://transport.integration.sl.se/v1/sites/*/departures

    När jag ber ChatGPT att skapa ett sådant får jag följande skript som SL då borde titta på och exekvera om dom tycker det stämmer. Jag har som sagt var inte testat det, så använd på egen risk.

    (Dokumentation hittas här https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesPathPattern)

    # 1. Set your variables
    DIST_ID="YOUR_DISTRIBUTION_ID"
    ORIGIN_ID="YOUR_ORIGIN_ID"

    # 2. Get current config with ETag
    aws cloudfront get-distribution-config --id "$DIST_ID" > config.json
    ETAG=$(jq -r '.ETag' config.json)
    jq '.DistributionConfig' config.json > dist-config.json

    # 3. Add the new cache behavior (this replaces dist-config.json with the modified version)
    jq '
    .CacheBehaviors.Items += [{
    PathPattern: "/v1/sites/*/departures",
    TargetOriginId: "'$ORIGIN_ID'",
    ForwardedValues: {
    QueryString: true,
    Cookies: { Forward: "none" },
    Headers: [],
    QueryStringCacheKeys: []
    },
    TrustedSigners: { Enabled: false, Quantity: 0 },
    ViewerProtocolPolicy: "allow-all",
    MinTTL: 5,
    DefaultTTL: 5,
    MaxTTL: 5,
    Compress: true,
    SmoothStreaming: false,
    AllowedMethods: {
    Quantity: 2,
    Items: ["GET", "HEAD"],
    CachedMethods: {
    Quantity: 2,
    Items: ["GET", "HEAD"]
    }
    },
    LambdaFunctionAssociations: {
    Quantity: 0,
    Items: []
    },
    FunctionAssociations: {
    Quantity: 0,
    Items: []
    },
    FieldLevelEncryptionId: ""
    }]
    | .CacheBehaviors.Quantity += 1
    ' dist-config.json > new-dist-config.json

    # 4. Update the distribution
    aws cloudfront update-distribution \
    --id "$DIST_ID" \
    --if-match "$ETAG" \
    --distribution-config file://new-dist-config.json
    Kristofer
  • Hej!

    Problemet orsakades av en uppdatering för hela API:et, där departures-endpointen fick en felaktig konfiguration. Det ska vara uppdaterat sen en ungefär en timme sen, nu ska endpointen inte längre ha någon cache över huvud taget enligt vad jag har förstått från SL. Cloudfront headers finns kvar, men kommer rapportera en miss.

    Hälsningar,
    Bert
    Bert på Trafiklab
  • Tack Bert,

    Jag kan bekräfta att följande API nu inte längre returnerar cache'ad information, vilket är precis vad som behövs:

    /v1/sites/{siteId}/departures

    Nedanstående API returnerar numera också ej cache'ad information, vilket inte skadar användare av API'et men kanske skapar onödig påfrestning på backend, då "sites" troligtvis inte ändras ofta alls så borde kunna vara kvar i cache. Men som sagt var inte ett problem för användare.

    /v1/sites

    De kvarvarande API'erna returnerar cache'ad information vilket är helt OK.

    /v1/lines
    /v1/stop-points
    /v1/transport-authorities

    Tack för att du hålt oss uppdaterade,

    -Kristofer
    Kristofer

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.