Continuous crash on opening older story file

[nparkinglot]

Describe the bug.

Uploaded and opened an older story, client crashes on opening after upload. Receive this message: b@https://twinery.org/2/static/js/main.952862b1.chunk.js:1:64539 ot/i<@https://twinery.org/2/static/js/main.952862b1.chunk.js:1:160077 ot@https://twinery.org/2/static/js/main.952862b1.chunk.js:1:160457 Zi@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:579770 kl@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:625876 gs@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:618638 vs@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:618561 ls@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:615570 Qo/<@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:567048 t.unstable_runWithPriority@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:642275 Ko@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:566757 Qo@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:566995 Yo@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:566928 R@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:636040 Yt@https://twinery.org/2/static/js/2.f537e56c.chunk.js:2:544212

Steps to reproduce:

Open twine Upload story file Open story file

Expected behavior:

File should open without crash

Additional context on this problem.

No response

Twine version number

2.5.1

Does this problem occur with the web version of Twine or the desktop app?

Web

What operating system does this problem occur on?

Windows

If this problem is occurring with the web version of Twine, what browser does it occur on?

Firefox

Presubmission checklist

• [ ] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
• [X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
• [X] I have read and agree to abide by this project's Code of Conduct.

[klembot]

Could you attach the file that causes the crash here?

[K8fractal]

I was able to reproduce this issue. Stories made July 2017 and before seem to crash. Stories modified 1/12/2018 and newer don't crash. I've had mixed results on stories published to file on 1/10/2018. I've attached two files that crash.

If I refresh the page after a file crashes, I am then able to view the story.

Old twines that crash.zip

[K8fractal]

On further investigation, the same crash occurs in Edge and Chrome on Windows as well.

[K8fractal]

I'm interested in working on code that would fix this bug.

Here's what I figured out so far. In the Windows Electron App, I get the error message:

An error occurred: There is no story format with name "Harlowe" and version "".

The files that cause this issue are missing the format-version="" attribute in <tw-storydata>. This means that formatWithNameAndVersion from story-formats/getters.ts is throwing an error.

After refreshing, the story has updated the format-version to the latest version which is why reloading fixes this.

[klembot]

@K8fractal a code contribution would be appreciated because I see crashes like this intermittently but have never been able to get it to happen predictably. What were you thinking re: approach on fixing this?

[hituro]

Duplicate of #1216 and #1265

[hituro]

@K8fractal if you are submitting a patch for this, note that a missing format attribute triggers the same error

[K8fractal]

@hituro Thank you for the additional information and test file pointers!

@klembot I have two possible approaches.

1. Make formatWithNameAndVersion more resilient. If a version number is missing, update to the latest version of the story file. If the format attribute is missing, use a default format. I've done the first part of this fix here, which did solve the crash for my example files.

2. Run repairStory() when importing a story and/or when opening a story. When reloading, repairStory() runs, which I assume is why reloading fixes this bug (and #1216).

I think approach 2 is better since it doesn't duplicate logic.

[greyelf]

If a version number is missing, update to the latest version of the story file. If the format attribute is missing, use a default format.

If either/both of these actions occur then the end-user should be informed of such, so they know that what action was done on their behalf. That way the end-user won't be surprised when their project doesn't behave or compile as expected.

eg. if the missing format was Adventures and the default one is Harlowe then the generated Story HTML file won't display the first Passage correctly.

[klembot]

@K8fractal I prefer option 2 strongly too. We used approach 1 in Twine 2.3 and it led to unexpected behavior where people would get surprised by the format version that was used during publishing, for example.

I was going to write that I think we only need to run the repair on import, but then someone could modify their story file while Twine was open, and repairing is nearly instaneous, so I like your idea of running it in both cases.