BigQuery Storage Write API: LimitExceededBehavior of FlowControlSettings is ignored in JsonStreamWriter

[tkosse]

Environment details

Java version: 8 latest
Library version(s): 2.8.1

Steps to reproduce

1. Create a new JsonStreamWriter with FlowControlSettings set

FlowControlSettings flowControlSettings = FlowControlSettings.newBuilder()
      .setLimitExceededBehavior(FlowController.LimitExceededBehavior.ThrowException)
      .build();
JsonStreamWriter writer = JsonStreamWriter.newBuilder(tableName, tableSchema)
      .setFlowControlSettings(flowControlSettings)
      .build();

2. Simulate service unavailability. After reaching the inflight quota limit writer.append(jsonArr) blocks indefinitely.

Stack trace

io.vertx.core.VertxException: Thread blocked at sun.misc.Unsafe.park(Native Method) at
    java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at
    java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163) at
    com.google.cloud.bigquery.storage.v1.StreamWriter.maybeWaitForInflightQuota(StreamWriter.java:322) at
    com.google.cloud.bigquery.storage.v1.StreamWriter.appendInternal(StreamWriter.java:310) at
    com.google.cloud.bigquery.storage.v1.StreamWriter.append(StreamWriter.java:272) at
    com.google.cloud.bigquery.storage.v1.JsonStreamWriter.append(JsonStreamWriter.java:147) at
    com.google.cloud.bigquery.storage.v1.JsonStreamWriter.append(JsonStreamWriter.java:99)
    ...

Any additional information below

During service problems like omg/48020 or other changes, that affect writing data to BigQuery we must avoid to indefinetly get blocked in our application. We can't afford that our application crashes or hangs because we are not able to ingest data to BigQuery. Instead we would rather have our application discarding those BigQuery events and trigger an alert. If the library would throw an exception instead of blocking, which this LimitExceededBehaviour seems to be intended for, this would be sufficient for us. So in this case WE could decide what to do when the limit is reached and not the library decides to block. This has real dramatic impact if this is permanently blocking due to a bug like omg/48020 and never recovers. To work around this with future bugs we implemented the same inflight quota counting on top and start discarding events before the the library internal quotas are reached. This is obviously not a good solution.

[tkosse]

Hey, are there any plans when this will be implemented?
Are you open for a pull request regarding this feature? If yes, what other things need to be considered when implementing this feature besides the contribution guidelines?

[stephaniewang526]

Hi, this is a nice-to-have feature which has not yet been prioritized. Definitely encourage community contribution. Please name your PR and initial commit something like feat: add support.... Also, make sure to include unit and integration tests in your PR to speed up the review process. We will then review it and provide feedback. Thanks!