Usefulness of EnumeratorBuilder wrapper

[bdewater]

I've been wondering why this exists since it seems unused. The documentation states:

job-iteration/lib/job-iteration/enumerator_builder.rb

Lines 14 to 21 in c904035

	# These wrappers ensure we have a custom type that we can assert on in
	# Iteration. It's useful that the `wrapper` passed to EnumeratorBuilder in
	# `enumerator_builder` is _always_ the type that is returned from
	# `build_enumerator`. This prevents people from implementing custom
	# Enumerators without wrapping them in
	# `enumerator_builder.wrap(custom_enum)`. We don't do this yet for backwards
	# compatibility with raw calls to EnumeratorBuilder. Think of these wrappers
	# the way you should a middleware.

The mention of middleware seems to indicate a way for things like ThrottleEnumerator to be implemented, but right now it seems to only calculate the size of the enumerator (I'm not sure how useful this actually is).

Maybe there's some Shopify internal usage I'm not aware of but my guess is that's not the case given these comments: #91 (comment)

#445 also made it possible to do things around iterations using callbacks.

Try as I might, I can't come up with a use case for it? Seems the options are:

• add a deprecation warning for unwrapped enumerators, fix the unwrapped enumerators here, document how custom enumerators should wrap)
• deprecate the wrapper (if used) and remove the thing
• do nothing 🤷

[bdewater]

I ran into @kirs at Rails World and we briefly chatted about this, he confirmed that Shopify's monolith uses the wrapping for a bunch of additional job queue functionality, so deprecation warnings seem the way to go.