Openhood Experiments

We recently bought a new Logitech MX3S mouse to use on MacOS. It’s a nice mouse and while it works most of the time, recently we experienced cursor stutter. It looks like the cursor lags behind the mouse movements.

After switching from using the Bolt receiver to Bluetooth, installing, re-installing the Logitech app. Trying the mouse on a Windows machine (no issue there). We finally found a way to make it work properly on MacOS Ventura:

Step 1:

Go to the Apple menu  > System Settings > Displays and click on the Advanced… button at the bottom:

Step 2:

There disable Universal Control by checking off Allow your pointer and keyboard to move between any nearby Mac or iPad.

Your brand new mouse should finally work as expected all the time.

One last thing, if you’re wondering why the Logitech Firmware Update Tool never find your mouse… the reason is simply there is no firmware update available… Thanks to their wonderful UX for making us loose time trying to figure out what we did wrong.

If you ever had to work with a GraphQL API featuring a few slow queries, you’ll probably understand the need to be able to cancel apollo-client queries. I’m using apollo-client 3.2.5, the latest at the time of writing. Since apollo-client uses fetch, my first attempt to cancel a query was using abortController:

interface CancellablePromise<T> extends Promise<T> { cancel: () => void }

export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> {
  const abortController = new AbortController()
  let promise = apolloClient.query({
    ...options,
    context: {
      fetchOptions: {signal: abortController.signal}
    }
  }) as CancellablePromise<ApolloQueryResult<any>>
  promise.cancel = () => abortController.abort()
  return promise
}

It partially works: the request is cancelled, and the promise doesn’t complete. However there’s a big issue: subsequent calls of the same query with the same variables don’t work anymore, no attempt is being made. You can follow this pull request since it might one day be resolved: handle external fetch abort.

Not discouraged, I tried another method using watchQuery and the unsubscribe method:

interface CancellablePromise<T> extends Promise<T> { cancel: () => void }

export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> {
  const observable = apolloClient.watchQuery(options)
  let subscription: ZenObservable.Subscription
  let promise = new Promise((resolve, reject) => {
    subscription = observable.subscribe(
      (res) => resolve(res),
      () => reject()
    )
  }) as CancellablePromise<ApolloQueryResult<any>>
  promise.cancel = () => subscription.unsubscribe()
  return promise
}

The logic behind it is that the call to unsubscribe should cancel the request when the browser supports it. However, that just doesn’t happen for me using Google Chrome (version 86.0.4240.111), the promise doesn’t complete however the request isn’t cancelled and subsequent calls of the same query with the same variables don’t work. It seems like I’m not the only one to have noticed, you can track the progress on this issue in the hope that it get fixed at some point: Unsubscribing from a query does not abort network requests.

You can find a few more opened issues related to cancelling apollo-client requests:

• Unmounting Query component no longer cancels network request in v2.6.0 & v3 beta
• updateQuery merging different data when changing query while fetchMore is not yet finished
• Cancel fetchMore network requests

After searching more about it, I found out about queryDeduplication, it’s apparently the reason why subsequent calls to cancelled queries don’t work anymore: the request is still considered to be “in-flight” and thus no further attempt is being made. Thus our code can become:

interface CancellablePromise<T> extends Promise<T> { cancel: () => void }

export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> {
  const abortController = new AbortController()
  let promise = apolloClient.query({
    ...options,
    context: {
      fetchOptions: {signal: abortController.signal},
      queryDeduplication: false
    }
  }) as CancellablePromise<ApolloQueryResult<any>>
  promise.cancel = () => abortController.abort()
  return promise
}

This time it finally works: the request is cancelled, the promise doesn’t complete, the next call of the same query with the same variables can complete successfully and subsequent calls will be retrieved from cache.

It’s also possible to combine watchQuery, abortController and queryDeduplication disabled:

export function cancellableQuery(options: QueryOptions<any, any>): CancellablePromise<ApolloQueryResult<any>> {
  const abortController = new AbortController()
  const observable = apolloClient.watchQuery({
    ...options,
    context: {
      fetchOptions: {
        signal: abortController.signal
      },
      queryDeduplication: false
    }
  })
  let subscription: ZenObservable.Subscription
  let promise = new Promise((resolve, reject) => {
    subscription = observable.subscribe(
      (res) => resolve(res),
      () => reject()
    )
  }) as CancellablePromise<ApolloQueryResult<any>>
  promise.cancel = () => {
    abortController.abort()
    subscription.unsubscribe()
  }
  return promise
}

The result is the same as the previous version, with no further benefit that I could see. Finally, I also tried to change the fetchPolicy to network-only but as far as I could see it only prevents the completed queries from being retrieved from cache, which isn’t something which I need.

If you’ve experienced really slow downloads from within VirtualBox on Mac, chances are you’re using the default NIC for your NAT interface.

I’ve seen docker’s pull taking ages when a layer size is more than a couple MB and chef installer taking more than 10mn to download the package…

Here’s how to fix it in docker-machine and test-kitchen.

For docker-machine

Check what’s your docker-machine VM’s name:

docker-machine ls

it will give you something like the following (could be different depending of your config):

NAME           ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
default        -        virtualbox   Running   tcp://192.168.99.100:2376           v1.12.5

if it’s Running, then stop it first:

docker-machine stop default

then change the NIC to use the PCnet-FAST III (Am79C973) instead of the default Intel PRO/1000 MT Desktop (82540EM):

VBoxManage modifyvm "default" --nictype1 "Am79C973"

And finally start it, it will now use the new NIC with “hopefully” improved speed:

docker-machine start default

For test-kitchen

Update your kitchen.yml or kitchen.local.yml to have your vagrant driver include the customize config below:

driver:
  name: vagrant
  customize:
    nictype1: "Am79C973"

Enjoy using all your available bandwidth!!

This article has been moved over our dedicated Openhood Games blog.

This article has been moved over our dedicated Openhood Games blog.