KRW & YEN balances ballooned up after update to 1.5.4

[laur89]

Suspect last update has introduced a regression that changes values of existing expenses.

Describe the bug Have a travel group that contains couple transactions in EUR, a few more in KRW and a bunch in YEN. EUR entries look fine, but the amounts of all transactions in other two currencies have ballooned up. Quite sure dinners at low-mid end restaurants in Tokyo didn't cost us to the tune of 2-5k EUR a pop for a party of four.

To Reproduce Steps to reproduce the behavior:

1. Create transactions (preferably in YEN & KRW) in earlier version(s) from 29th of Sep onwards; note docker image has been auto-updated daily to the latest tag around 1AM CET.
2. Yesterday version was updated to 1.5.4
3. Witness existing KRW & YEN transactions making little sense - as in the values are crazy high:

Expected behavior I'd expect, at a minimum, to have the ledger show immutable transactions, instead of seeing them change and having to figure out what they're supposed to be.

App version (note container creation time from latest tag was 2025-10-19T14:23:51.196437623Z)

$ docker inspect 4c754caedca3  # the container
[
    {
        "Id": "4c754caedca39bf9755dd0e92c774f466226238503a0b007e1b1324e150ebd53",
        "Created": "2025-10-19T14:23:51.196437623Z",
        "Path": "docker-entrypoint.sh",
        "Args": [
            "sh",
            "start.sh"
        ],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 463948,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2025-10-20T03:34:16.683768001Z",
            "FinishedAt": "2025-10-20T03:33:58.526888054Z"
        },
        "Image": "sha256:527a5459bfbbbb11c9811d5102a7b0ac1a78af8b7b4be240ea592f5031fe90ba"

$ docker inspect 527a5459bfbb   # the image
[
    {
        "Id": "sha256:527a5459bfbbbb11c9811d5102a7b0ac1a78af8b7b4be240ea592f5031fe90ba",
        "RepoTags": [
            "ossapps/splitpro:latest"
        ],
        "RepoDigests": [
            "ossapps/splitpro@sha256:68cfcbea0bc929a2b98411719caedb63f7cb7fe90de2e76451ddb5c10bd6a566"
        ],
        "Parent": "",
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2025-10-19T10:22:23.304778953Z",
        "DockerVersion": "",
        "Author": "",
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "NODE_VERSION=22.16.0",
                "YARN_VERSION=1.22.22",
                "NODE_ENV=production",
                "SKIP_ENV_VALIDATION=false",
                "COREPACK_ENABLE_DOWNLOAD_PROMPT=0"
            ],
            "Cmd": [
                "sh",
                "start.sh"
            ],
            "ArgsEscaped": true,
            "Image": "",
            "Volumes": null,
            "WorkingDir": "/app",
            "Entrypoint": [
                "docker-entrypoint.sh"
            ],
            "OnBuild": null,
            "Labels": null
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 336083651,
        "GraphDriver": {
            "Data": null,
            "Name": "btrfs"
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:08000c18d16dadf9553d747a58cf44023423a9ab010aab96cf263d2216b8b350",
                "sha256:816163c8de126bb86476e07a621b5336c40f2b68ff137a8d8924ab2298dd3b55",
                "sha256:9456de7b6fb0b4c9fc5cd771213fd757a2dee0d943781718fa2057f8935ac952",
                "sha256:b2a0dc9be1c54c4cd4389d7257bf8d7bf6fcd367462be3425f8c497ff5ecd654",
                "sha256:2f0c3a8ea0fa2b2153d9b1f890827817fe1b461b8071416f1de4e4dd36e354a0",
                "sha256:8df51d18db36e951944b624c5cffd8b686d0192dc944a7d364b71e3c1e89c57e",
                "sha256:77425f7b634d7dda56e731f5218fdd04f341fe259c2fda72faae822fc6926a43",
                "sha256:a52496a8013551fcc72c7fc28abf30721c38075fd448c344c4ce46e0ab3527a4",
                "sha256:501ae6d2f66fbcfc493e16368956a1c35a1ea23d1feee5f8eb90b140578ad723",
                "sha256:e73202564ce90b3fc1499301090ffab4485e041316c38ce108e1850aeabdd1be",
                "sha256:b863ef910d60575c51ae399077b8d2831ea5a144007979e17d469daeb538c4f1",
                "sha256:78bb4454f9ca7e4712b64de6edacf2f3f0c32f3e639b7fa2bae9c98f858793f1",
                "sha256:e6e1dece42b9eb5007fa835368414dcde491eeae74a133f03e733d2f2d5fa906",
                "sha256:3a3684ef088335a50fc3c581ed9f3d72844e5861ed2dcf5f12ca0a50be7f71dc",
                "sha256:d1a203d34b0a42fc076373fdddaa194c85ba33d8554f0958f0df783e3eea0e6f",
                "sha256:62f478422e6d1b40509606a6a8297f2df3ceec58c683a77246ccd379d28307ee",
                "sha256:6819b50e1a7e11277027bc54977bc43dd321c760a5392a020a81e89b26e2339a",
                "sha256:bdf4fc80d68c9f08d56a2dc8617d5bf11f651906f857dfb62a87392c041af37b"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

[krokosik]

Ah, my bad. I implemented localized currency inputs and presentation, but the underlying values remained shaped as if all had USD decimals. Could you confirm that the balooning corresponds to a shift by two decimal points (for yen and krw)?

[laur89]

Have access to only one tx info atm, but that seems to be the case - two decimal points have been added on.

Can you confirm the data in db is correct (i.e. no migrations) and it's merely a front-end presentation bug?

[krokosik]

The data in DB has not changed, I will make a migration soon.

[krokosik]

I'm afraid I can't release this migration as a hotfix release, since it is a breaking change and would break semver. I see the following options:

1. include the script as an optional migration you can invoke with docker exec and release inside of the 1.5.5 image
2. wait for the 1.6 release and make it a proper migration

I am more in favor of the first option, as I am afraid that the script I made (see PR) could impact someone's data negatively if they for some reason used fractional numbers in their splits or in case of the 3 decimal currencies, treated the mismatch as rounding.

Let me know which option you'd prefer.

[laur89]

I can downgrade to 1.5.3 in the meantime and wait for 1.6.0, no?

[krokosik]

Yes of course

[krokosik]

Hello @laur89, I reached the conclusion that it might be safer (and not that troublesome) for users to perform the migration manually rather than sneak it under the hood.

1. Download the migration script.
2. Copy it to your docker compose file directory
3. Execute cat migrations.sql | docker exec -i splitpro-db psql -U postgres -d splitpro

Remember to adjust the container name/db user/db name if needed.

I will leave the issue open for a time and add this instruction to the 1.6 release.

[laur89]

If it's a manual step, then it sounds more like a breaking change requiring a major version bump IMHO. But duly noted.

[krokosik]

True, but too late for that unfortunately. It's more of a hotfix now