Repository navigation
Provide better story for individual migration results #16016
Description
Activity
- changed the title
[-]Failed updated shows a confirmation message, but successful one doesn't[/-][+]It is not clear if the update finished successfully or not[/+]on Nov 1, 2019 This was previously not an issue because the CLI did not print any message stating that the migration was successful or not. Now with V9 of the CLI, it always prints
Migration successful. This is not correct since migrations can be simply incomplete or failing gracefully (for various reasons).e.g. most of the time migrations have edge cases which cannot be handled automatically. In those cases user action is required and it does not make sense to make the user think that the migration was successful/complete.
If a migration can stop midway, it shouldn't print this indication though:
Could not migrate all undecorated classes that use dependency injection. Some project targets could not be analyzed due to TypeScript program failures. Migration can be rerun with: "ng update @angular/core --from 8.0.0 --to 9.0.0 --migrate-only"This is incorrect because many packages can be updated at the same time. In this example it is only correct to use
--migrate-onlywith@angular/coreif that was the last package to be updated. But the migration does not know this.The update procedure itself should indicate how to resume from an interrupted migration, and show the full command to resume all un-fully-migrated packages.
I don't quite follow why that would be incorrect. The migration coming from
@angular/corejust asks the developer to re-run the migrations for@angular/coresince the migration from core failed and manual action is needed. Previous migrations which were successful as part of@angular/coreand will be scheduled twice if the given command is ran a second time, will just be a noop.Agreed that this is something the CLI could do, but at the time of writing this is not available and we achieved something similar by printing such a message. We did this in version 8 too.
It's incorrect because the original command was
ng update @angular/core @angular/cli --next. The migrations for@angular/climight not have happened yet when the update process was interrupted.So running
ng update @angular/core --from 8.0.0 --to 9.0.0 --migrate-onlydoes not get you to the same place as if the migration had not been interrupted. To do that you'd need instead to dong update @angular/core @angular/cli --from 8.0.0 --to 9.0.0 --migrate-only(including CLI as well).Why would the migrations from
@angular/clibe relevant though for that particular migration that failed? It's true that the CLI migrations can change things too, but from the perspective of the@angular/coremigration, the only prerequisite is that there is an TS project.If you are saying that the
@angular/coremigrations are dependent on migrations of the CLI, then I'm not sure if that is the right thing. I'd expect the the core migrations to be not dependent on migrations outside of the@angular/corescope. In general though.The way you are describing the issue is that followed migrations will be interrupted. This is not the goal and not the case currently. The goal is:
- All followed migrations continue executing.
- But only the incomplete migration will be re-run manually (with the given command)
- Other migrations as part of
@angular/coreran already and will be a noop.
- Other migrations as part of
Ah I see. Yes I did think that the last migration interrupted the process and prevented the remaining ones from executing.
So that does sound right. We should somehow indicate that some migrations need extra attention and might require action.
Reacted by Paul GschwendtnerThe problem is that if you are handling an error gracefully, it means that the migration was successful. Because a migration fails when either a workflow event of type error or an exception were triggered.
My 2 cents on the way forward here would be;
- In the schematics, if there is an error, it should be thrown. As otherwise it will always be with a successful result.
- In the CLI when a one of the migrations fail we don't stop the other migrations. We continue running the other migrations.
4 remaining items
Message change was merged to
masterand9.0.xbranches. I'll leave this issue open since it seems to be a larger challenge which will require a greater redesign to address. If that is being tracked elsewhere, then we can maybe close this issue.Yeah this looks as good a place to track it as any.
Reacted by Paul Gschwendtner@alan-agius4 I feel differently. An example is that a migration cannot handle all patterns automatically and requests the developer to manually take action. In those case the migration is not successful nor complete. This is actually quite common since migrations most of the time are limited by the possibilities of static analysis. I agree that we could rethink how errors are handled (e.g. not gracefully exiting), but in terms of this issue, it seems to unveil the general issue where the CLI makes an assumption. It's wrong to assume that a migration is complete or successful if it didn't throw. There should be an API to communicate back to the CLI what the status is (for purposes like printing how to rerun the migration). In any case though (except when an error is thrown), the CLI should not make any assumption IMO.
A larger expansion and refactoring is planned and will include a structured migration system. However, at the current juncture the migrations will need to work within the current confines of the system. This unfortunately means that the migrations themselves will need to contain more boilerplate and infrastructure than should ideally be needed. But this will improve as update is updated.
- changed the title
[-]It is not clear if the update finished successfully or not[/-][+]Provide better story for individual migration results[/+]on Nov 14, 2019 - added a commit that references this issue
on May 29, 2026
This issue impacts 9.0.0-rc.0 and happened while updating https://github.com/johannesjo/super-productivity and https://github.com/SAP/cloud-commerce-spartacus-storefront.
A failed update will show a message saying both the individual migration and the update failed:
The update below did not finish successfully however, and instead just shows the last migration as successful (@devversion confirms this). In this case the migration shows an error that it seems to suggest was actually recovered from, but it fact the intent is that the migration was interrupted and should later be resumed.
A completely successful migration will look the same as the migration above though:
We should confirm the update finished, was successful, or if it was interrupted midway and should later be continued.