Eco 4788 investigate proxy browser failures #1769
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I accidentally created this duplicate in 89c0761.
It’s not used, and the property doesn’t actually exist on the Defaults const (type assertion means compiler doesn’t catch it).
Currently, if you create a client with logHandler and/or logLevel
options, these options will affect all existing client objects. This
means that code like the following doesn’t do what you’d expect — the
log messages emitted by firstClient will say "secondClient":
```
const firstClient = new Realtime({
logHandler: (msg) => console.log("firstClient: ", msg),
})
const secondClient = new Realtime({
logHandler: (msg) => console.log("secondClient: ", msg),
})
```
Here we fix this as much as we can within the limitations of the
existing public API (see usage of defaultLogger). I _think_ that using
the default logging config is the right thing to do in the situations
where we have a standalone function or static method that doesn’t accept
logging configuration, but you could also argue that we should instead
maintain global effects for these usages and use the last-set logging
configuration. I don’t think it hugely matters because we actually only
end up falling back to defaultLogger in:
- the tests (that’s fine, we’ll see the console output)
- reporting failure of functions that are directly invoked by the user
and which throw an error upon failure anyway (i.e. even if the log
message doesn’t go where the user expected, they’ll still be informed of
the event the message described)
I’ve kept the Logger.logAction* static methods instead of changing them
to instance methods, because that way they remain easy for our
strip-logs plugin to target.
Created #1766 for updating ably.com documentation.
Resolves #156.
Resolves ECO-4786.
For upcoming interception proxy. TODO: once I’ve got rid of the subsequent commit with the old Python code, put this into the later commit instead
Implemented entirely as an mitmproxy addon. Abandoned because it didn’t give me sufficient control over WebSocket connection lifetimes.
This reverts commit ff30f2c. (I just want to keep it in the Git history for now, in case for some reason it’s useful to return to.)
…prototype - start-interception-proxy adapted from https://github.com/ably/sdk-test-proxy at 82e93a7 Some TODOs which aren’t really important right now because this is just a prototype: - TODO fix type checking for interception proxy — `npm run build` does it properly, but tried to reproduce the way we do it for modulereport and it didn’t work - TODO fix linting for interception proxy — doesn’t seem to be catching lint errors - TODO linting / type checking etc for Python code - TODO investigate test failures in browser: - Firefox is passing - [Chromium is failing](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087173): > ``` > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087173#step:15:35514)- offers realtime presence functionality > > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087173#step:15:35515)- is able to use the web_socket transport > > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087173#step:15:35516)- is able to subscribe to and unsubscribe from channel events, as long as a MessageFilter isn’t passed > > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087173#step:15:35517)- can take a MessageFilter argument when subscribing to and unsubscribing from channel events > ``` > - [WebKit is failing](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087922): > ``` > failed tests: > > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087922#step:15:27042)- allows you to use push admin functionality > > [](https://github.com/ably/ably-js/actions/runs/8802125604/job/24157087922#step:15:27043)- allows you to use push admin functionality > ``` TODO how to get WebKit working locally on my Mac? Adding to keychain didn’t seem to work Also: > Add test:playwright:open-browser script > > Lets you open a headed browser which is configured to use the > interception proxy. Useful for local debugging of browser tests.
(My mistake when I wrote these tests.)
|
OK, the proxy connection limit thing is now fixed, so Chromium is now fixed. Still getting the WebKit push admin modular tests failure. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.