Skip to content

Conversation

@stephenplusplus
Copy link
Contributor

No description provided.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Sep 15, 2016
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 6393317 on stephenplusplus:spp--ci-speed-up into 35573c3 on GoogleCloudPlatform:master.

@stephenplusplus stephenplusplus changed the title tests: ci: see if eachLimit stops AppVeyor errors tests: ci: allow parallel npm installs Sep 15, 2016
@stephenplusplus
Copy link
Contributor Author

stephenplusplus commented Sep 15, 2016

@callmehiphop this has sped up our builds quite a bit!

image

screen shot 2016-09-15 at 8 07 19 am

Previously, each environment would require around ~15-17 minutes just to run npm installs, before running any tests. Now we've got it down to ~8-17 for the tests to complete.

- 4
- 0.12
- 4
- 6

This comment was marked as spam.

@coveralls
Copy link

coveralls commented Sep 15, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling f4effa6 on stephenplusplus:spp--ci-speed-up into 35573c3 on GoogleCloudPlatform:master.

- packages\resource\node_modules -> packages\resource\package.json
- packages\storage\node_modules -> packages\storage\package.json
- packages\translate\node_modules -> packages\translate\package.json
- packages\vision\node_modules -> packages\vision\package.json

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@coveralls
Copy link

coveralls commented Sep 15, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 0c9dd98 on stephenplusplus:spp--ci-speed-up into 35573c3 on GoogleCloudPlatform:master.

@coveralls
Copy link

coveralls commented Sep 15, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling 0aeafa6 on stephenplusplus:spp--ci-speed-up into 35573c3 on GoogleCloudPlatform:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 0aeafa6 on stephenplusplus:spp--ci-speed-up into 35573c3 on GoogleCloudPlatform:master.

@stephenplusplus
Copy link
Contributor Author

Even though it took 100 commits, this should be an improvement over what we have now. It might take more tweaking, but that's just another 100-commit PR away.

@callmehiphop callmehiphop merged commit af8ca8d into googleapis:master Sep 19, 2016
miguelvelezsa pushed a commit that referenced this pull request Jul 23, 2025
[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [protobufjs](https://protobufjs.github.io/protobuf.js/) ([source](https://togithub.com/protobufjs/protobuf.js)) | [`7.2.6` -> `7.3.0`](https://renovatebot.com/diffs/npm/protobufjs/7.2.6/7.3.0) | [![age](https://developer.mend.io/api/mc/badges/age/npm/protobufjs/7.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/protobufjs/7.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/protobufjs/7.2.6/7.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/protobufjs/7.2.6/7.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/) |

---

### Release Notes

<details>
<summary>protobufjs/protobuf.js (protobufjs)</summary>

### [`v7.3.0`](https://togithub.com/protobufjs/protobuf.js/blob/HEAD/CHANGELOG.md#730-2024-05-10)

[Compare Source](https://togithub.com/protobufjs/protobuf.js/compare/protobufjs-v7.2.6...protobufjs-v7.3.0)

##### Features

-   add handling for extension range options ([#&#8203;1990](https://togithub.com/protobufjs/protobuf.js/issues/1990)) ([2d58011](https://togithub.com/protobufjs/protobuf.js/commit/2d58011cc0bc495c68ed70f5aad297deb1722378))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "after 9am and before 3pm" (UTC), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about these updates again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/googleapis/gax-nodejs).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4zNTEuMiIsInVwZGF0ZWRJblZlciI6IjM3LjM1MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
sofisl pushed a commit that referenced this pull request Feb 3, 2026
## Description

This PR achieves the same objectives as https://togithub.com/googleapis/java-bigquery/pull/4010, but for Node as requested in [the planning sheet](https://docs.google.com/spreadsheets/d/1cHAw6cV8k_s40hw28C8STtlymu3MXEvTY6PaKgdgSGE/edit?resourcekey=0-hPyTawvew5ugN037XCfZXg&gid=0#gid=0). The idea is that for reading rows, the users should be able to access high precision values for timestamps if high precision values are being stored on the backend.

## Impact

This PR follows a test driven development approach against the getRows method.

Tests were written to evaluate what happens when getRows receives various input values for timestampOutputFormat and useInt64Timestamp. These tests revealed that not only are high precision values not being delivered to users for ISO8601_STRING return types, but also other bugs exist like calls hang on getRows calls that fail and conversion logic throughs errors for some calls that fetch rows. This PR fixes all the bugs and ensures the values with the right precision are delivered to users.

This chart details the before code changes / after code changes results with impact highlighted in green:

<img width="1575" height="383" alt="image" src="https://togithub.com/user-attachments/assets/75c1ff70-073c-477e-9363-8eff5be0aa5f" />

The highlighted green impact shows that conversion logic has been updated to avoid the  'cannot convert' errors and with this new logic changes are also applied to the BigQueryTimestamp class to maintain high precision on timestamp values returned to users.

## Testing

New system tests to capture all useInt64Timestamp/timestampOutputFormat combinations for getRows calls.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes This human has signed the Contributor License Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants