Update the `/treasury migrate` command to use the latest concurrency code. about treasury

[Jikoo]

Migrating on the main thread is a great way to get shut down by the watchdog while transferring larger data sets. Perhaps instead the current provider should be set to a dummy economy that always returns FAILURE? That way not only do you not risk the server killing itself due to the main thread lockup, players can still play using non-economic features while the economy is being migrated.

[MrNemo64]

We propably want to do all the migration on the main thread, If we do it async some plugin may use the old economy provider while switching.
If a plugin is already fetching async we should probably block untill we finish (dont know how).
What do you think of EconomyProviderMigrationStartEvent and EconomyProviderMigrationFinishEvent

[lokka30]

We propably want to do all the migration on the main thread, If we do it async some plugin may use the old economy provider while switching. If a plugin is already fetching async we should probably block untill we finish (dont know how). What do you think of EconomyProviderMigrationStartEvent and EconomyProviderMigrationFinishEvent

I think it should be done on the main thread, and if possible, block the async threads too.

What plans do you have for the new events? I don't see an issue in creating them but I don't know what they are used for :)

[MrNemo64]

What plans do you have for the new events? I don't see an issue in creating them but I don't know what they are used for :)

I don't know, maybe some plugin find it useful

I think it should be done on the main thread, and if possible, block the async threads too.

Blocking on async threads, if an operation is being made, it may start with currency A and end with B, dont know how many problems that can cause. Maybe post this on the spigot thread an see ideas

[Geolykt]

It's best if we rip out that code in the meantime so we have something that compiles and people can link to

[MrNemo64]

Migrating on the main thread is a great way to get shut down by the watchdog while transferring larger data sets. Perhaps instead the current provider should be set to a dummy economy that always returns FAILURE? That way not only do you not risk the server killing itself due to the main thread lockup, players can still play using non-economic features while the economy is being migrated.

I like this idea. Maybe even add a isMigratingEconomyProvider so that we can check? But how would we handle operations that already started?

[Jikoo]

Maybe even add a isMigratingEconomyProvider so that we can check?

I assume if you wanted to check you could check the implementing class. I guess you could include it as part of the API, but it seems like a very particular use thing that I'm not sure belongs. Your average plugin shouldn't care, they'll just see that the transaction fails and that's that. It's such a rare case too, I sincerely doubt you'd be converting more than maybe once a year if you happen to have particularly bad luck with economy providers.

But how would we handle operations that already started?

Probably would need some sort of EconomyProvider#awaitPendingQueries, but this also overall seems like one of those overkill situations - even the slowest of response times is unlikely to exceed a second, so what are the odds that someone started a transaction that will coincide with your once-per-year economy migration? Additionally, bad actors who just grab and hang onto the first available EconomyProvider instead of reobtaining it as necessary can still create new queries using the old economy instance unless the provider actually verifies that it's still registered every single time it's used.

^{Speaking of I need to go back and change my RegisteredServiceProvider usage for Vault integrations to listen to the ServiceRegisterEvent and ServiceUnregisterEvent instead of plugin enable/disable, whoops.}

[lokka30]

Maybe even add a isMigratingEconomyProvider so that we can check?

I assume if you wanted to check you could check the implementing class. I guess you could include it as part of the API, but it seems like a very particular use thing that I'm not sure belongs. Your average plugin shouldn't care, they'll just see that the transaction fails and that's that. It's such a rare case too, I sincerely doubt you'd be converting more than maybe once a year if you happen to have particularly bad luck with economy providers.

But how would we handle operations that already started?

Probably would need some sort of EconomyProvider#awaitPendingQueries, but this also overall seems like one of those overkill situations - even the slowest of response times is unlikely to exceed a second, so what are the odds that someone started a transaction that will coincide with your once-per-year economy migration? Additionally, bad actors who just grab and hang onto the first available EconomyProvider instead of reobtaining it as necessary can still create new queries using the old economy instance unless the provider actually verifies that it's still registered every single time it's used.

Speaking of I need to go back and change my RegisteredServiceProvider usage for Vault integrations to listen to the ServiceRegisterEvent and ServiceUnregisterEvent instead of plugin enable/disable, whoops.

Since the migrator withdraws the money from the previous provider, I think it is fine if we do it completely async and don't worry about any transactions that occur during the migration process as the user can just migrate again to get the new balances in.

Also - migrating economies whilst users are on - doesn't sound like a good idea to me anyways 😄

[lokka30]

Note: This issue is being addressed in #37.