Fix batch parameter requirements

[jack-berg]

Fixes a bug which has been present since the original introduction of standard environment variables in #666 and the original trace SDK spec #205.

@breedx-splk points out that there's no need for the export batch size to be less than the queue size since an export batch size smaller than the queue can still drain a queue in multiple exports.

On the other side of things, an export batch size large than the queue will always fully drain the queue with each export. And so you could say there's no reason for the export batch size to be larger than the max queue size, but its hardly worth restricting.

[reyang]

What's the benefit of this change? I think the current version can help to prevent user mistakes (e.g. if someone tries to change the batch size to 500, while the queue size is 100, SDKs have a chance to throw exception or warn the user so they can fix the problem ahead of time).

[chukunx]

Thanks @jack-berg for bring up the discussion and @reyang for chiming in. My two cents: the original restriction (max batch size <= max queue size) acts as a safeguard to catch potential misconfigurations and inform users when they are (or are about to be) running into unintended or undefined behavior. At the specification level, this helps enforce consistent behavior across languages.

However, each language may introduce implementations that provide additional flexibility or functionality based on language features and user needs, etc. Such implementations may be beyond the scope of the specification IMHO.

As a reference on this matter, I took a quick look at some implementations (I’m not familiar with each language, so SMEs, please feel free to correct me if needed):

• Java: as @jack-berg pointed out in one of the issues, users may choose to set a larger max batch size than the max queue size (and opt out of their warranties).
• Go: max batch size is adjusted to be less than or equal to max queue size.
• Python: en error is raised if max batch size exceeds max queue size
• JS: max batch size is adjusted to be the (smaller) max queue size, and a warning message is logged
• Ruby: en error is raised if max batch size exceeds max queue size
• Rust: max batch size is adjusted to be the (smaller) max queue size

It does look like these languages enforce the current restriction.

[jack-berg]

Thanks for that @chukunx! To @reyang's point, I don't know of any use cases that are enabled by a looser restriction here. Without a use case in mind and with all the implementations (except java which I consider a bug) producing an error or effectively ignoring this configuration as invalid, I don't see any reason to loosen the requirement.