Update Bank Account information

BNAndras · February 13, 2025, 8:40pm

Related to [Bank Account] Instructions mention race conditions; tests do not check for race condition - #3 by BethanyG, but the canonical test data indicates this exercise can be implemented without concurrency.

github.com

exercism/problem-specifications/blob/47b3bb2a1c88bf93d540916477a3b71ff94e9964/exercises/bank-account/canonical-data.json#L6


      
          {
            "exercise": "bank-account",
            "comments": [
              "This exercise is a good candidate to practice concurrency, which",
              "may not be available or possible in the implementing language track.",
              "It is possible to implement this exercise without concurrency."
            ],
            "cases": [
              {
                "uuid": "983a1528-4ceb-45e5-8257-8ce01aceb5ed",
                "description": "Newly opened account has zero balance",
                "property": "bankAccount",
                "input": {
                  "operations": [
                    {
                      "operation": "open"

However, the instructions indicate concurrency is expected though because it references avoiding race conditions.

github.com

exercism/problem-specifications/blob/47b3bb2a1c88bf93d540916477a3b71ff94e9964/exercises/bank-account/instructions.md?plain=1#L6


      
          # Instructions
          
          Your task is to implement bank accounts supporting opening/closing, withdrawals, and deposits of money.
          
          As bank accounts can be accessed in many different ways (internet, mobile phones, automatic charges), your bank software must allow accounts to be safely accessed from multiple threads/processes (terminology depends on your programming language) in parallel.
          For example, there may be many deposits and withdrawals occurring in parallel; you need to ensure there are no [race conditions][wikipedia] between when you read the account balance and set the new balance.
          
          It should be possible to close an account; operations against a closed account must fail.
          
          [wikipedia]: https://en.wikipedia.org/wiki/Race_condition#In_software

The way I see it is we either should update the instructions to remove references to concurrency and race conditions or remove the comment about skipping concurrency in the canonical test data.

In the former, tracks may want to add an append if concurrency is expected.

In the latter, tracks without concurrency may want to forego the exercise.

IsaacG · February 13, 2025, 9:19pm

Moving the concurrency stuff to an append and adding that to the tracks that use it seems reasonable to me. I’m not sure if there’s any way to shove a common/shared append blurb in the problem spec repo.

Cool-Katt · February 14, 2025, 7:02am

I vote for putting the concurrency bit in an append, or a note block.

tasx · February 16, 2025, 7:53pm

It’s not just the instructions that talk about concurrency, but the intro as well

github.com

exercism/problem-specifications/blob/47b3bb2a1c88bf93d540916477a3b71ff94e9964/exercises/bank-account/introduction.md

# Introduction

After years of filling out forms and waiting, you've finally acquired your banking license.
This means you are now officially eligible to open your own bank, hurray!

Your first priority is to get the IT systems up and running.
After a day of hard work, you can already open and close accounts, as well as handle withdrawals and deposits.

Since you couldn't be bothered writing tests, you invite some friends to help test the system.
However, after just five minutes, one of your friends claims they've lost money!
While you're confident your code is bug-free, you start looking through the logs to investigate.

Ah yes, just as you suspected, your friend is at fault!
They shared their test credentials with another friend, and together they conspired to make deposits and withdrawals from the same account _in parallel_.
Who would do such a thing?

While you argue that it's physically _impossible_ for someone to access their account in parallel, your friend smugly notifies you that the banking rules _require_ you to support this.
Thus, no parallel banking support, no go-live signal.
Sighing, you create a mental note to work on this tomorrow.
This will set your launch date back at _least_ one more day, but well...

tasx · February 16, 2025, 8:13pm

In my view, the best option would be to decide whether this exercise is truly about concurrency. I don’t see why it should be optional. This isn’t just an extra test that doesn’t affect the exercise — it completely changes how the exercise is approached, right? Wasn’t this one of the featured exercises on concurrency in the 2023 concept challenges?

So, the best course of action, i believe, would be to remove the optional aspect from the specs, and make concurrency mandatory. Without concurrency, the exercise becomes trivial.

Edit: Also, tracks that have implemented this exercise most likely included concurrency as well. If we go with the append approach, every one of those tracks would need an append file.