Running locally doesn't read/write the latest data

[Towerful]

Hello,
This is a great tool! So, thanks!

I ran into this problem when I was figuring out how this package works, and it made it really difficult to figure out what I needed to do!
I also don't have a solution to it, other than a lot of emulator reloads.

I tried running a migration against my local emulators, but it only ever returned 1 document.
I exported the data from my emulators, restarted them and re-imported the data, then the migration found the additional documents.
I think I had 1 document in the collection I was migrating when I first loaded the emulators and dry-ran the migration. I then added more documents for more testing, which it never picked up.
I had to export the new data from the emulators, restart the emulators, then reimport the data for it to be picked up by fireway.

Also, the saved migration details seemed to disappear, but still function for fireway.
So, I would run a v0.0.1 migration against the local emulators. It would do its thing.
No new collection called fireway would turn up in the emulators, however fireway would no longer run that migration version.
I looked through all my firebase projects in case it had leaked to a dev/prod project, however I didn't see it in any of them.

Once I confirmed my migrations (with lots of emulator restarts), everything ran fine on my dev/prod projects.

[kevlened]

I'm glad you appreciate it! It sounds like something strange was going on in your dev environment. I run all the tests against a local instance of Firestore, so running locally should work. If you create a small repo to reproduce the problem, I can check it out.

[Towerful]

I'll have a look tomorrow.
It might very well be my dev environment, as I have multiple deployments and multiple web apps in each.

Thinking on it some more, I hadn't configure the service account details when I was encountering this.
So that might have cause oddities with the emulators.

[kiptoomm]

I have experienced a very similar, if not the same, issue. In most cases when I already have some migrations entries in the 'fireway' collection, the newest migration script is not triggered at all:

$fireway migrate
Found 3 migration files
Executing 0 migration files
Finished all firestore migrations
Files scanned:3 executed:0
Docs added:0 created:0 updated:0 set:0 deleted:0

In some cases, restarting the Firebase emulator and rerunning fireway migrate seems to work (i.e., the most recent migration script actually gets executed)

[kevlened]

Hmm. Perhaps the output could show the last migration that was executed. To be executed, new migrations must have a higher version than the last executed migration

[kiptoomm]

Hmm. Perhaps the output could show the last migration that was executed. To be executed, new migrations must have a higher version than the last executed migration

Sure that would help, but the bigger issue IMO is why sometimes it is necessary to restart the emulator (unfortunately, there doesn't seem to be consistency to that behavior)

[kevlened]

I think I'm a bit confused. If the emulator dumps the db when it's restarted, then all the migrations will be rerun. That makes sense, no?

[kiptoomm]

Sorry, I forgot to mention this important detail: when running the emulator, I almost always import data from previous runs of the emulator

firebase emulators:start --import=test/local-dev --export-on-exit=test/local-dev

So yeah you're right that all the migrations would be rerun if I was starting with a fresh db every time

[kevlened]

Ah. In that case, I'm unsure. I would need additional details in the output (like what fireway thought the last migration was vs what it actually is vs what's in the migrations directory). Unfortunately, I can't commit to working on this repo in the short to mid term (weeks to months).

[kiptoomm]

Fair enough. In any case, this feature would help:

the output could show the last migration that was executed

[ylno]

I have the same or a very similar problem. I do not see the changes that fireway makes in the emulator. Unfortunately exporting and re-importing the emulator data does not help me either. The state of the db remains the same.

When I run fireway twice in a row, the shell output looks correct: the first time the migrations are executed. The second time fireway recognizes that the migrations have already run. But the view of the data in the emulator ui still shows the old data.

Until recently I did not have these problems and could test the migrations locally. A colleague who has an identical setup cannot reproduce the problem. For him, the data is changed correctly.