This change removes ConfigModule from FlowComponent, since it's already present in all of the standard components that serve as "parents" to FlowComponent (i.e. it's in FrontendComponent, BackendComponent, ToolsComponent, and EppTestComponent). ConfigModule should only ever be included in top-level components, so that it's possible to swap it out without having to make changes deep within subcomponent code.
This change also removes SystemSleeperModule, which belongs at the top-level component as well, and is present in BackendComponent and ToolsComponent but was absent in FrontendComponent and EppTestComponent. I've added it to those two places.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140053552
To add additional logic for flow code, write custom classes that extend the existing custom logic classes (of which DomainCreateFlowCustomLogic is the first provided example), along with a class that extends CustomLogicFactory to provide instances of the new custom logic classes. Then configure the fully qualified class name of your new custom logic factory in ConfigModule.provideCustomLogicFactoryClass().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139221577
This allows handling of N asynchronous deletion requests simultaneously instead
of just 1. An accumulation pull queue is used for deletion requests, and the
async deletion [] is now fired off whenever that pull queue isn't empty,
and processes many tasks at once. This doesn't particularly take more time,
because the bulk of the cost of the async delete operation is simply iterating
over all DomainBases (which has to happen regardless of how many contacts and
hosts are being deleted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133169336
See [] for details, but basically, @FlowScope causes the Flow instance produced by flowProvider.get() in FlowRunner to be the same each time it's called, which leads to the instance being re-used when a transactional retry (e.g. for a ConcurrentModificationException) causes a flow to be attempted more than once. Flow is not meant to be re-used and certain flows fail at runtime when this happens, so the effect is that a CME now aborts most EPP requests, which is bad.
This is a bit of a hacky fix; finding a better one is tracked in []
== TESTING ==
This is very hard to test because there isn't really a clean way to trigger a CME from within a flow's execution without hardcoding in assumptions about what a given flow is doing when it runs, and we can't easily supply a custom Flow for testing while also exercising the Flow daggerization process (since this bug only appears due to the specific way that dagger constructs the Provider<Flow>). Ideally a fix would improve the testability here as well.
For now, I've manually tested this change by pasting code into FlowRunner that explicitly throws a ConcurrentModificationException after running the flow (similar to DryRunException), but only on the first transaction attempt. With @FlowScope on provideFlow(), this change reproduces the UnsupportedOperationException issue in many tests; once it's removed (i.e. with this CL submitted) the problem goes away.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126226066
This is more efficient (we were constructing all the
providers and the map anew for every flow) and prettier.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125479328
Daggerizes all of the EPP flows. This does not change anything yet
about the flows themselves, just how they are invoked, but after
this CL it's safe to @Inject things into flow classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125382478
