Noen bugs i Norsk Tipping AS github knyttet til jakartaee/concurrency, som kan skape risiko for det en har sett i medier

[lania]

Noen bugs i Norsk Tipping AS github knyttet til  jakartaee/concurrency, som kan skape risiko for det en har sett i medier

Norsk Tipping feil: Menneskelig svikt førte til lottogevinster som var multiplisert med 100
 

Er skrevet i artikkelen:

"Fredagens sak skjer i kjølvannet av flere omtalte feil hos Norsk Tipping det siste året:

• Selskapet er ilagt en bot på 46 millioner kroner etter at VG avslørte feil i den nasjonale trekningen i «Eurojackpot-millionen».
• Norsk Tipping har også fått 36 millioner kroner i bot fordi selskapet i mange uker opplevde feil i muligheten til å utestenge seg selv fra spill dersom man brukte et Apple-produkt.
• I tillegg fikk en spiller, ved en feil, utbetalt 25 millioner kroner, etter å ha spilt på Kong Kasino hos Norsk Tipping. En slik premie er i strid med regelverket. Spilleren betalte pengene tilbake til Norsk Tipping da feilen ble oppdaget. Norsk Tipping fikk en bot på 2,5 millioner kroner."

 

 

Hvis en bruker copilot i github, så kan en enkelt finne bugs - Dette burde departementet, samt medier, gjøre på egenhånd slik at eventuelle feil i større grad blir fjernet.

 

 

Copilot fra github fant følgende, for akkurat concurrency:

"

Here are some potential bugs and risky areas identified in the jakartaee/concurrency code, especially in the concurrency test classes. These are based on a semantic search for bugs and common issues:

---

1. Risk of NullPointerException and ClassCastException

In VirtualThreadServlet.java, there are multiple places where code like the following appears:

Java

 

Thread thread = (Thread) results.poll(1, TimeUnit.MILLISECONDS);
Object result = results.poll(1, TimeUnit.MILLISECONDS);

if (result instanceof Throwable)
    throw new AssertionError("An error occured on thread.", (Throwable) result);

• Risk: If results.poll() returns null (because the queue is empty or the timeout expires), a NullPointerException may occur when you try to use result later or when casting to Thread.
• Recommendation: Always check for null before casting or further usage.

---

2. Potential for Flaky Tests Due to Timing

There are several usages of timed polling and waiting in the tests, such as:

Java

 

assertTimeoutPreemptively(TestConstants.waitTimeout, () -> {
    for (; 2 != results.size(); Wait.sleep(TestConstants.pollInterval)) {
        // Wait till we have exactly 2 results indicating 1 run of schedule
    }
});

• Risk: Timing-based tests can be flaky, especially under heavy load or slow CI environments. If the task doesn’t complete in time, tests may intermittently fail.
• Recommendation: Consider using more robust synchronization or increasing timeouts (with explanatory comments).

---

3. Calling .get() or .poll() Without Handling Timeout or Exceptions

Example:

Java

 

Object result0 = results.get(0).get(1, TimeUnit.MILLISECONDS);

• Risk: If the result is not available within 1 millisecond, a TimeoutException will be thrown, possibly causing the test to fail unexpectedly.
• Recommendation: Use more reasonable timeouts, and ensure you catch and handle exceptions appropriately.

---

4. Repeated Use of assertEquals(null, ...)

Example:

Java

 

assertEquals(null, started.poll(1, TimeUnit.SECONDS));

• Risk: This checks that the queue is empty, but if a spurious wakeup or late task occurs, the assertion may fail even though the code is correct.
• Recommendation: Consider if this assertion is strictly necessary or if a more robust check is warranted.

---

5. Potential Transaction Status Staleness

In AnnotationServlet.java:

Java

 

int status = checkContextAndGetTransactionStatus.call();
// ... transaction rolled back ...
int status = checkContextAndGetTransactionStatus.call();

• Risk: After rolling back the transaction, reusing the same callable may give unexpected results if the context isn't reset properly.
• Recommendation: Ensure that the callable's context is stateless or properly reset between uses.

---

6. Potential Copy-Paste Errors in Documentation

In jakarta-concurrency.adoc:

AsciiDoc

 

Callable<Long> agency2 = ctxSvc.createContextualProxy( new CreditScoreTask(taxID, 2), Callable.class));
Callable<Long> agency3 = ctxSvc.createContextualProxy ( new CreditScoreTask(taxID, 3), Callable.class));

• Risk: There are extra closing parentheses at the end of both lines, which would cause a compilation error if copied as code.
• Recommendation: Remove the extra ).

---

Summary:
Most issues are related to concurrency testing practices—timing, null handling, exception handling, and possible documentation typos. Review these areas for more robust, reliable, and safe code."

Endret 28. juni av lania