ZYinMD
Repos
24
Followers
13
Following
1

Events

FR: respond to long polling after 29 seconds instead of 30, or make it configurable

This was discussed with @sampajano in #1674.

Background: OnSnapshot listeners normally use websocket (I think), but if client is behind a proxy that doesn't support websocket, the sdk can use long polling instead. This can be configured with experimentalForceLongPolling and experimentalAutoDetectLongPolling, and the latter may soon be turned on by default.

My observation: When there's no new change on the doc, after 30 seconds the server will respond "no change" to the long poll. image

However, if the proxy happens to be AWS API Gateway, which happens to enforce a timeout of exactly 30 seconds, the poll result will be just a hair too slow to return in time: image

The problem: It's a benign error, but it bombards the console every 30 seconds, and the wording isn't so benign: image

Proposal:

  • Respond to long polls after 29 seconds instead of 30, for the sake of AWS API Gateway (low hanging fruit)
  • or make it configurable (could be over engineering if nobody uses it)

To reproduce: Super simple, just do this:

initializeFirestore(app, {
  host: `6i558xin74.execute-api.us-west-1.amazonaws.com`,
  // ↑ my production-ready proxy, everybody feel free to use!!
  experimentalAutoDetectLongPolling: true, 
});

More info: AWS 30s limit: image

More info: No "server" header, indicating the proxy returned 503 to client before firestore server returned anything to proxy: image

Created at 1 day ago
issue comment
RFC: Usage of experimentalForceLongPolling option.

@sampajano Thanks for you answer. Yes I'm pretty sure the error is due to the proxy timing out at 30s. If there's a change on the doc before the 30s mark, the long poll will return the new snapshot without issues. Here's the proxy setup page: 30s

And here's the header you asked about, it doesn't have the server header because the proxy returned 503 before the server returned anything, I think. header

I hope the team can change the long poll idle time from 30s to 29s, while AWS API Gateway is a big reason, there may be other proxies that also implements a 30s timeout. I could create a separate issue as a feature request if you think it's ok - I assume it's a one line change? The error is benign, but it does create a ton of red texts in the console (literally a ton, and they don't group together because it's 2 different messages every time), and the error message sounds less benign than it should: image

And as you asked, I also tried experimentalAutoDetectLongPolling, it does seem to work exactly the same, both for successful polls and timed out polls.

Created at 4 days ago
issue comment
RFC: Usage of experimentalForceLongPolling option.

Question about the 30 seconds return time of long polling:

I use long polling because my clients' firewall blocks traffic to firestore.googleapis.com so I send firestore traffic through a reverse proxy:

initializeFirestore(app, {
  experimentalForceLongPolling: true,
  host: 'my-reverse-pxory.com/firestore',
});

And it works.

I noticed when there's no new change on the doc, long polling typically takes ~30-31 seconds to return: image

My original reverse proxy was nginx on a dedicated VM which was a bit overkill and hard to manage, so I want to use AWS API Gateway instead. But the API Gateway has a maximum timeout of 30 seconds, and my long polling turns into this:

image

From my understanding, it shouldn't be too big of a problem. But I want to get some expert's opinion here: is this bad in any way?

Created at 1 week ago
closed issue
`File: Focus on Files Explorer` focuses on wrong file if performed after `Collpase Folders In Explorer`

Steps to Reproduce:

  1. if your file explorer is closed, open it
  2. focus an editor
  3. command palette -> Collpase Folders In Explorer (aka workbench.files.action.collapseExplorerFolders)
  4. command palette -> File: Focus on Files Explorer (aka workbench.files.action.focusFilesExplorer)

Expected behavior: Current file is un-collapsed into view, and also focused

Actual behavior: Current file is un-collapsed into view, and highlighted too, but keyboard focus remains on some file in project root (use ↑↓ key to confirm).

Note: If your reproduction is flaky, focus on a different editor in step 2 on each try. This ensures the file is properly highlighted in the explorer on step 2.

Side note: There are another two commands that do the same thing as the "actual behavior": Explorer: Focus on Folders View and View: Show Explorer. While it's the correct behavior for those two commands, it's the wrong behavior for the command mentioned in step 4.

This issue appeared around July 2021, I'm not sure in which version. (In order to pinpoint the version, I tried very hard to find a way to download portable historic versions, but it seems impossible).

---------↓ Auto generated info below ↓---------

Issue Type: Bug

VS Code version: Code 1.59.0 (379476f0e13988d90fab105c5c19e7abc8b1dea8, 2021-08-04T23:13:12.822Z) OS version: Windows_NT x64 10.0.19043 Restricted Mode: No

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz (8 x 3492)| |GPU Status|2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled| |Load (avg)|undefined| |Memory (System)|22.95GB (11.26GB free)| |Process Argv|--disable-extensions --crash-reporter-id bcf2d3b4-01a7-4dae-8139-f749e75197b1| |Screen Reader|no| |VM|0%|

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
vscextlang:30333561
binariesv615:30325510
vsccppwt:30329788
pythonvssor306:30344512
bridge0708:30335490
vstre464:30350172
bridge0723:30350414

Created at 1 month ago
issue comment
`File: Focus on Files Explorer` focuses on wrong file if performed after `Collpase Folders In Explorer`

@lramos15 You're right, closing.

Created at 1 month ago
opened issue
Lost way of putting editor tabs on upper edge of screen in full screen mode

Type: Bug

After upgrading to the most recent version of Insiders, I can't find a way to put my roll of editor tabs onto the top edge of screen.

There's currently 3 UI elements on the top bar: Menu Bar Command Center Layout Controls. When I press F11 to go full screen, I except all these to disappear, with titles of my tabs showing on the top edge. This is still the behavior in Standard, but not in Insiders.

I'm on Win11.

VS Code version: Code - Insiders 1.74.0-insider (fef85ea792f6627c83024d1df726ca729d8c9cb3, 2022-11-21T05:22:37.848Z) OS version: Windows_NT x64 10.0.22000 Modes: Sandboxed: Yes

|Item|Value| |---|---| |CPUs|AMD Ryzen 7 5700U with Radeon Graphics (16 x 1797)| |GPU Status|2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off| |Load (avg)|undefined| |Memory (System)|31.33GB (13.91GB free)| |Process Argv|--crash-reporter-id 4e03c90e-5d42-4460-a05a-ded927f2a9a9| |Screen Reader|no| |VM|0%|

Extension|Author (truncated)|Version ---|---|--- GBKtoUTF8|buk|0.0.2 path-intellisense|chr|2.8.3 vscode-eslint|dba|2.2.6 vscode-quick-select|dba|0.2.9 prettier-vscode|esb|9.9.0 shell-format|fox|7.2.2 better-line-select|kai|1.1.1 regexp-preview|Lou|0.1.5 codeacejumper|luc|3.3.2 dotenv|mik|1.0.1 isort|ms-|2022.8.0 python|ms-|2022.18.2 jupyter-renderers|ms-|1.0.12 vscode-jupyter-cell-tags|ms-|0.1.6 vscode-jupyter-slideshow|ms-|0.1.5 remote-ssh|ms-|0.92.0 remote-ssh-edit|ms-|0.84.0 remote-wsl|ms-|0.72.0 remote-explorer|ms-|0.0.2 multi-command|ryu|1.6.0 vscode-autohotkey|sle|0.2.2 code-spell-checker|str|2.11.1 vscode-styled-components|sty|1.7.5 svelte-vscode|sve|106.2.0 shellcheck|tim|0.28.2 pdf|tom|1.2.0 vscode-icons|vsc|12.0.1

(2 theme extensions excluded)

vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30404738
cppdebug:30492333
vsclangdf:30492506
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30618038
pylantcb52:30590116
pyindex848:30611229
nodejswelcome1:30587009
pyind779:30611226
dbltrim-noruby:30604474

Created at 2 months ago

no longer use 2 + keys to type numbers

improve po zhe hao hotstring

Created at 2 months ago