Add support for configuration of profile

Fix #23
Add the command preevy profile configure:
Usage examples:
# View current configuration
preevy profile configure ->

Current configuration for kube-pod:
namespace:     test123
server-side-apply: false

# Update namespace for kube-pod driver
preevy profile update --kube-pod-namespace=abc ->

Updated profile configuration
Current configuration for kube-pod:
namespace:     abc
server-side-apply: false

# Update namespace for kube-pod driver
preevy profile update --unset=kube-pod-server-side-apply ->
# Or
preevy profile update --unset=server-side-apply ->

Updated profile configuration
Current configuration for kube-pod:
namespace:     abc

Good idea, I think in general, we should always allow specifying the --profile flag.

Do you mean making it required? IMO the current profile is a good default.

In terms of the flags command name, it's a bit too technical, I think.

Maybe "defaults" then?

The problem with set key1=key2 is that it's not part of the flags and doesn't appear in the help command like the flags.

We can make the args help return the driver flags' help. Help can be dynamic and depend on the state stored in the profile (i.e, the driver flag) to show only the chosed driver's flags.

What do you think about: preevy profile config -> show profile config.  preevy profile config update {flags} {or --set} -> update and print new config. preevy profile config reset -> reset default values and prompt the interactive init.

I'm not sure what "profile config" means, it's too generic and it covers stuff that is not default flags. See suggestion about "defaults".
It's confusing that there is an implicit "list" subcommand here. When a subcommand is not specified it lists the defaults, but there is also an explicit "update" subcommand?
Reset and start from scratch is a bad UX for changing a single option. As a user I would rather mash the enter key on all questions to leave my answers as is as is until I get to the one thing I want to change.


Add workflow to automatically trigger upgrade-provider run

Add workflow to automatically trigger upgrade-provider tool to execute ./upgrade-provider pulumi-{PKG}... whenever pulumi-bot opens an upstream upgrade PR

@iwahbe I can add this workflow to a single provider and test it before rolling out to all providers

@iwahbe this should be good now. The same workflow in pulumi-newrelic (https://github.com/pulumi/pulumi-newrelic/actions/runs/4640148249/jobs/8211770787) succeeded in dispatching the upgrade provider job in upgrade-provider (https://github.com/pulumi/upgrade-provider/actions/runs/4640149034/jobs/8211799799 - still fixing that)


Change index.html page and experience.js page

@riyajha2305 is it merged?

no, not yet

@ @riyajha2305 merge it first


WIP: Add queryCache de/rehydration

This is a continuation of things described in issue #461. It's a breakout from the closed PR #570 and builds on the merged PR #584.
This PR adds a couple of new public APIs:

dehydrate(queryCache)
dehydrateQuery(query)
hydrate(queryCache, dehydratedQueries) which returns a initializeQueries()-function
A new initialQueries-prop for ReactQueryCacheProvider Was removed in favor of:
useHydrate(dehydratedQueries) - A hook that does hydrate and initializeQueries for you

Together, this provides a way to dehydrate a cache, pass its serialized form over the wire or persist it somehow, and later hydrate those queries back into an active cache. Main goal is to improve support for server rendering, but this might also help with things like persisting to localstorage or other storage.
An important feature of these new APIs is that the shape of the dehydrated cache is meant to be a private implementation detail that consumers should not rely on, which needs to be emphasized in the docs. This means that the de/rehydrate functionality can more easily be built upon in the future without breaking changes.
This PR is missing types and API-docs for now (which is why it's WIP). Examples and longer guides for the docs are probably best tackled in follow ups?
SSR Example with Next.js

❗ This example previously looked different, but has been updated for useHydrate

A minimal example (not tested/verified to work, but should):
// _app.js
// We need to include the CacheProvider at this level to
// avoid blowing away the cache on each page transition
import { ReactQueryCacheProvider } from 'react-query'

export default function MyApp({ Component, pageProps }) {
  return (
    <ReactQueryCacheProvider>
      <Component {...pageProps} />
    </ReactQueryCacheProvider>
  )
}

// routes/Page.js
import { makeQueryCache, useQuery } from 'react-query'
import { dehydrate, useHydrate } from 'react-query/hydration'

const fetchData = async () => 'Pretend this is fetched from an API...'

export const getStaticProps = async () => {
  const queryCache = makeQueryCache()

  await queryCache.prefetch('key', fetchData)

  return {
    props: {
      dehydratedQueries: dehydrate(queryCache)
    }
  }
}

function Child() {
  const { data } = useQuery('key', fetchData)

  return data
}

export default function Page({ dehydratedQueries }) {
  useHydrate(dehydratedQueries)
  return (
    <Child />
  )
}

Questions
These are a few questions I'm not totally certain about myself and might be worth an extra look when reviewing.
Should hydration be its own entry point?

Solved, is now its own entry point

Should dehydrateQuery be included in the official APIs?
dehydrateQuery could be left out of the public APIs but I included it because I can imagine this could be useful for building things like incremental/differential dehydration in userland (as I think I've seen in some GitHub-discussions). This lets users build their own solutions for dehydration at the query level (persisting only new queries to localstorage for example), while still hiding the specific shape and relying on the official hydrate.
A bigger public API is harder to maintain though, so if we feel the usecase is unclear here it could easily be made private in this PR and be made public later if needed.
Does separating hydrate and initializeQueries and therefor the buildQuery-refactor make sense?
When using the low level hydrate(), it returns a function initializeQueries that when called loops through the queries that were hydrated and schedules them for staleness and garbage collection. The reason this was separated in two can be seen in ReactQueryCacheProvider, where I didn't want to schedule setTimeouts in render.
Since I wanted to reuse the internal buildQuery and that had the cache creation and side effects mixed, I had to refactor that as well. It was split into two calls to new lower level functions, so all old tests are passing and behaviour for existing things are unaffected in this PR.
Afterward I realized useQuery etc actually does schedule setTimeout etc in render since it calls buildQuery. I'm not sure if this is intended or not. If it's intended, the approach and API in this PR might be unnecessarily complex. If it's unintended, it should be quite easy with this refactor to also move the setTimeouts to useEffects in the useQuery-functions in a follow up.
How should we handle updatedAt?

Solved, updatedAt is now hydrated and also used for determining how far into the future staleness should be scheduled.

Can naming be improved?

I'm sure I've missed a bunch of stuff I wanted to highlight and/or ask, but hopefully this is a good start for getting feedback and questions. 😅

I'm loving this. I think something we should consider here is making this its own bundle via rollup, then proxying it with a nested import:

Rollup creates similar packages for both the core and the hydration utilities. The existing stuff doesn't need to change, but we can add a new configuration to rollup for hydration and have it place the files in dist/hydration/...
Create a file in the root of the repo called hydration.js, which is essentially the same as /index.js, but points the hydration files instead.

This should keep the bundle size down for the default use case.

As for updatedAt, technically it is UTC because it uses Date.now(), right? Wouldn't this mean that it would be okay to included in the dehydration? Then really what should happen on hydration is that stale and garbage collection times should be based off of that time (or immediately, if it's too far in the past).

Sorry for the radio silence, busy summer. 😄

I'll go ahead and separate this out into it's own entry point.
I'm not sure why I brainfarted on the updatedAt, you are right of course. Requiring server time to be set correctly for staleness to work correctly isn't such a big ask so I think we should definitely base the stale time off of that when hydrating! I'll fix that too.

Another thing I've realized is that the Next-example in the description wont work since setting up the cache per page would blow away the entire cache on page transitions. This might mean we want to separate out the hydration-specific functionality from ReactQueryCacheProvider, possibly to a hook instead. This would also move that to the separate entry point as a bonus.
I'll start working on this now, but might take a little more time figuring out the details (and tests).
What do you think about releasing this as unstable_ or something similar at the start before we have docs, examples etc in place, as well as giving it some time to mature?

Okay, this PR has been updated with a bunch of stuff.

Hydration is now its own entry point react-query/hydration
initialQueries was removed again from ReactQueryCacheProvider, instead a new useHydrate-hook was introduced
updatedAt is now included when de/rehydrating
When scheduling staleness on hydration, it is now measured from the point in time the data was fetched on the server (updatedAt), instead of the time of hydration.

I also updated the description above, including the Next.js-example. Except for missing types, docs and examples I hope this is in a pretty good place now and ready for review. I still need to verify a few things so I'll leave the WIP on a while longer.
Two questions:

Should we make this an unstable feature at first to make sure it works as we've intended and for all use-cases before we commit to the design fully?
Which of types, docs and examples would you like to see in this PR as opposed to in follow-ups?

I am not quite sure where to put this (maybe in v3 issue) but the approach we took in our platform was wrapping react-query with our own thin layer that takes care of SSR preloading as well as named query support.
For SSR, I took a pretty naive approach where we use a Map store on the request context (through Next.js) and that store gets serialized to the page on render. I then override initialData in react-query to hydrate from that global storage when available. This lets us achieve most of what we want by using getInitialProps to execute and preload query data and get it hydrated on the client.
Pseudo usage
Homepage.js
import { pageHeading } from 'data/page-heading'

// pageHeadingData would be a query descriptor
// containing its name, queryFn, default options, etc.

export const Homepage = () => {
  const { data: heading } = pageHeading.useQuery(/* vars, options */);

  return (
    <h1>{heading}</h1>
  )
}

Homepage.getInitialProps = (ctx) => {
  await ctx.preloadInitialQuery(pageHeading/*, vars, options */)
  return {};
}

The preloadInitialQuery function inserts the query result into the context request cache:
async function preloadInitialQuery(ctx /* next.js context */, queryDescriptor, vars, options) {
  const { data, error } = await executeQuery(queryDescriptor, vars, options);
  if (!error) {

    // set the result for this query key
    // in the per-request context injection store
    ctx.queryStore.set(getQueryKey(queryDescriptor.id, vars), data);
  }
}

On render, the our app server would take that Map and inject it into the page like:
<script>
window.__QUERIES__ = {
  "<QUERY_KEY>": "<QUERY_RESULT>"
};

And our initialData would check for that:
initialData() {
  const queryKey = getQueryKey(name, vars);

  if (window.__QUERIES__[queryKey]) {
    return window.__QUERIES__[queryKey]
  }
  return undefined;
}

By using a Map as the generic store on the request, we were able to use this both within Next.js and outside Next.js (we have two different app servers that use our shared library).
Just wanted to share this approach for future reference/ideas! It works pretty well mainly due to our ability to use named/registered queries so we can always look them up and not have to pass queryFns around.

@kamranayub That's a neat solution when using the current React Query, thanks for sharing! What you are doing is essentially implementing a separate cache to use when server rendering, this PR is all about implementing support for this directly in the library so that you don't need to have that separate cache anymore. Besides hopefully reducing complexity for you, this also means:

We can transfer some config between server and client (staleTime, cacheTime, updatedAt for now)
We can set the query to become stale a certain amount of time after it was fetched on the server
We can support Suspense with SSR better in the future (or with third party solutions like react-ssr-prepass)
We better support things like persisting the cache to things like localstorage

You probably got this from the description already, just wanted to be clear on the motivations for implementing this as a first class thing. 😄
I'm curious, does it look like this PR would make things easier for you or is it missing something?
Btw, I think the named query registry is still a great idea for other reasons, you probably wanna keep that around either way. 💯

Yes, we were looking through this and I think it would help make it easier to integrate with! Since we have two app servers, a Next.js-based one and a custom one, the approach has to end up being able to support a "generic" integration.

Glad to hear that! I built this for use in a custom SSR solution myself, so it should absolutely support that.

Server

Create a cache manually for every request using makeQueryCache
Use yourQueryCache.prefetchQuery to prime the cache
Place cache on context with ReactQueryCacheProvider
Render app
Call dehydrate(yourQueryCache)
Serialize and embed result in payload like you are doing with window.__QUERIES__
Send payload

Client

Create a cache manually
Get dehydrated queries from window.__QUERIES__ (or whatever you called it)
Either:

Call hydrate(queryCache, dehydratedQueries) and the resulting initializeQueries() directly (low level)
Render (with ReactQueryCacheProvider)

Or:

Render (with ReactQueryCacheProvider)
Do useHydrate(dehydratedQueries) in child

Typing out a full example is a bit more verbose with custom SSR of course which is why I left it out of this PR. It will definitely be covered by docs and examples though!

useHydrate  seems like a strange API choice instead of something like
import React from "react";
import {render} from "react-dom";
import {hydrateCache} from "react-query/hydrate";

const hydratedQueryCache = hydrateCache(window.__QUERIES__);

render(
  <ReactQueryCacheProvider cache={hydratedQueryCache} />
    <App />
  </ReactQueryCacheProvider>
)

Is there a reason? Is it to keep things related to hydration out of the main entry point? triggering hydration of the cache using the global data from a child component and effectively passing it up the component tree seems wrong. IMO it would make more sense to provide it at the highest point in the component tree so parent state isn't updated by a child rendering

@pseudo-su Great question, this is something I definitely want feedback on so I'm glad you asked.
In Next.js, since we receive the dehydrated queries as props we need to hydrate the queries inside of render. This isn't necessarily great, but I know no other way to solve it currently. Hydrate consists of two parts, first we need to put the queries into the cache and then we need to schedule timeouts for staleness and garbage collection. The first one might not be great to do in render since it could be considered a side effect to add queries to an external cache, but at least it's idempotent, meaning that we can run it several times and get the same outcome, queries already in the cache wont be written over. Scheduling timeouts however is something that should probably happen in an effect instead. (Scheduling timeouts in render is something the other hooks like useQuery do today though, this PR also paves the way to change that if desirable)
When using custom SSR none of this is a problem and you can just do both before even rendering and in fact, the hydrate-function you are suggesting already exists in this PR! The only difference is that in order to separate putting queries into the cache and the scheduling of timeouts, the hydrate in this PR returns a function initializeQueries which you need to call to schedule the timeouts. This feels a bit wonky, and maybe the public API should just be a hydrate-function that does both that you can use in custom SSR, and a useHydrate that you can use inside of render, but if we want to support other frameworks in the future (or just usecases we haven't thought about), it might make sense to provide a low level API as well that lets you separate these. I do worry that it's easy to forget to call the function returned from hydrate though since the API is a bit unusual..
An earlier version of this PR had an extra initialQueries-argument to ReactQueryCacheProvider, but you might want to put hydration and the cache provider in different components. Separating it also means we can move hydration to a separate entry point to avoid increasing the JS-payload for people who don't use hydration. An alternative/complementary API to useHydrate could be to have a ReactQueryHydrator-component or something similar:
function ReactQueryHydrator({ queries, children }) {
  useHydrate(queries)
  return children
}

function App() {
  return (
    <ReactQueryCacheProvider>
      <ReactQueryHydrator queries={dehydratedQueries}>
        <Content />
      </ReactQueryHydrator>
    </ReactQueryCacheProvider>
  )
}

Hydration is purely behaviour though and the rest of React Query is hooks-based, so a hook seemed like a good fit. I'm very open to including such a component as well for conveniency though!
Another difference from your example is that in that, the hydrateCache-function seems to be the one actually creating the cache. This was considered in an earlier version of this PR (#570), but as an argument to makeQueryCache instead, similar to how libraries like Redux does it. I realized that we don't need to constrain ourselves to only hydrating at creation though, it might very well make sense to hydrate several different dehydrated queries and/or at different points in time, for example from both server rendering and localstorage.
To address what seems to be a main concern though, useHydrate isn't actually updating a top components state, only an external cache so the question is, will that update trigger a re-render somewhere? First of all, the queryCache itself is still the same, so ReactQueryCacheProvider wont re-render. Second, if a component is already listening to one of the queries that exists in the dehydratedQueries, this means that query has already been created in the cache (without data) and therefor wont be overwritten by the hydration, so even in that case no re-render should happen. This means useHydrate should only ever affect components further down in the tree which makes sense as you pointed out, you need to hydrate it before you use it.
This became somewhat of a wall of text, but I wanted to try to be as clear as I could about some of the tradeoffs and motivations about the current API design-choices. 😄 Even so, I think there is still room for improvement, so I'm very grateful for all feedback!

This became somewhat of a wall of text

As someone prone to writing accidental walls of text as well I appreciate the detail 😄. I'll try go through things point by point and then propose/elaborate some thoughts all at once at the end.

In Next.js, since we receive the dehydrated queries as props we need to hydrate the queries inside of render

That does explain why useHydrate is required. My knee-jerk response to that would be why impose hydrating the cache inside of rendering if/when people are doing basic/vanilla SSR without that limitation?

maybe the public API should just be a hydrate-function that does both that you can use in custom SSR, and a useHydrate that you can use inside of render

Wouldn't it be possible to expose the multiple hydration functions and just provide people with the useHydrate and a thing that coordinates them? from what I understand (which might not be accurate) something like:
const queryCache = makeQueryCache();

hydrate(queryCache).initQueries();

but if we want to support other frameworks in the future [...] it might make sense to provide a low level API as well that lets you separate these

I'm not exactly clear on which one of these are being considered as the "low level" vs "high level" API. personally I would consider the "low level" API to be the one that has no knowledge about react and is purely dealing with the queryCache. Which I think I would prefer to use.

An alternative/complementary API to useHydrate could be to have a ReactQueryHydrator component or something similar

If it was necessary to do hydration during the react render I'd personally find it preferable to have the <ReactQueryHydrator /> API (because otherwise everyone doing vanilla SSR has to create it themselves anyway), but I'm not clear on why anyone doing basic SSR would prefer that over just setting up the queryCache outside of react.

Separating it also means we can move hydration to a separate entry point to avoid increasing the JS-payload for people who don't use hydration

Makes sense wanting to keep the entrypoints seperate

Another difference from your example is that in that, the hydrateCache-function seems to be the one actually creating the cache

yeah that was just for terseness (and I wasn't aware of the need to hydrate and also have the seperate initializeQueries), I don't really think it's necessary to have an API that create+hydrates+initializes all in one, but I do think exposing a set of functions to do this would be preferable for anyone doing basic/vanilla SSR.

To address what seems to be a main concern though, useHydrate isn't actually updating a top components state

I did have a quick skim through the code and I saw that it's technically not updating a parent components state, but my first impression was that's what it's function was which made the API feel strange to me. It makes sense that if/when using certain SSR frameworks it's a limitation/requirement to do the hydration as part of the react render. For what it's worth it might just be the name, <ReactQueryHydrator queries={dehydratedQueries}> seemed clearer to me (all in all probably not a big deal tho).

Is something like this viable?
import React from "react";
import {render} from "react-dom";
import {makeQueryCache} from "react-query";
import {hydrateCache} from "react-query/hydrate";
const queryCache = makeQueryCache();
hydrate(queryCache, window.__QUERIES__).initQueries();
render(
  <ReactQueryCacheProvider cache={queryCache} />
     <App />
  </ReactQueryCacheProvider>
)

I think there's a real potential benefit of providing an API to use that's totally independent of the react render (not a provider and not a hook) and I think I can provide an example:
Currently I heavily use import() expression syntax in my client entrypoint which allows webpack to do automatic bundle splitting, it looks a bit like this
import "core-js/stable";
import "regenerator-runtime/runtime";

async function loadDependenciesAsync() {
  const loadReact = import(/* webpackPreload: true */ "react").then((m) => ({
    React: m.default,
  }));
  const loadApp = import(/* webpackPreload: true */ "./app");
  const loadLibComponents = import(
    /* webpackPreload: true */ "@mysite/lib-design-system"
  );
  const loadSsrToolbox = import(
    /* webpackPreload: true */ "@mysite/lib-ssr-toolbox/client"
  );

  // Not used directly but still critical-path can good to preload.
  // When making changes to this check the build/webpack.report.html to
  // see how it affects the resulting bundle.
  // prettier-ignore
  {
    void import(/* webpackPreload: true */ "react-dom");
    void import(/* webpackPreload: true */ "react-router");
    void import(/* webpackPreload: true */ "react-router-dom");
  }

  const allLoaded = await Promise.all([
    loadReact,
    loadApp,
    loadLibComponents,
    loadSsrToolbox,
  ]);

  const combined = Object.assign({}, ...allLoaded);

  return combined;
}

void loadDependenciesAsync().then((asyncDeps) => {
  const { React, hydrate, ThemeProvider, App, DefaultTheme } = asyncDeps;
  hydrate({
    render() {
      return (
        <ThemeProvider theme={DefaultTheme}>
          <App />
        </ThemeProvider>
      );
    },
  });
});

If the only API I have is one that runs during the react render then I have to wait for react (and potentially a whole bunch of other libraries) to load before being able to create and hydrate the queryCache. Alternatively with an API that allowed me to hydrate the cache outside of the react render I could do something like this and initialize the queryCache before/while the react JS bundle is downloading:

async function loadDependenciesAsync() {
  /* etc */
}

async function initQueryCache() {
  const {makeQueryCache} = await import("react-query");
  const {hydrateCache} = await import("react-query/hydrate");
  cosnt queryCache = makeQueryCache();

  // maybe this should fail in dev mode but not in prod mode
  await hydrate(queryCache, window.__QUERIES__).initQueries()

  return queryCache;
}

void Promise.all(loadDependenciesAsync, initQueryCache).then(([asyncDeps, queryCache]) => {
  /* etc */
})

@pseudo-su  ❤ for the detailed discussion!

That does explain why useHydrate is required. My knee-jerk response to that would be why impose hydrating the cache inside of rendering if/when people are doing basic/vanilla SSR without that limitation?

Just to clear up what seems to be a misunderstanding, we aren't imposing that, the API you are asking for is already included in this PR! It's slightly different (and I'm very open to changing the details), but this works:
import React from "react";
import {render} from "react-dom";
import {makeQueryCache} from "react-query";
import {hydrate} from "react-query/hydrate";

const queryCache = makeQueryCache();

const initQueries = hydrate(queryCache, window.__QUERIES__);
initQueries();

render(
  <ReactQueryCacheProvider cache={queryCache} />
     <App />
  </ReactQueryCacheProvider>
)

An extra detail to note here which is also pretty confusing to communicate is that queries should never be stale or garbage collected before the first render. This would mean different things could render on the server and first render, leading to hydration mismatches.
The example above is safe only because render happens immediately after initQueries, or at least in the same tick. If render would happen in a later tick because of some asynchronous event between them, this could mean trouble.. So await-ing initQueries is actually the opposite of what we want.. So in practice, initQueries should probably be run after the first render:
const initQueries = hydrate(queryCache, window.__QUERIES__);

render(/* ... */);

initQueries();

This is pretty confusing and I don't like this level of detail leaking into the public API, so this is a bit of a sore point currently, I'd love any suggestions to make this less confusing (maybe better naming would help somewhat?). An alternative safer API, but possibly less flexible, could be:
hydrate(queryCache, window.__QUERIES__).then(() => {
  render(/* ... */);
});

This way we could make sure to run the init behind the scenes after calling the thenable? Note that the return wouldn't be a Promise, but rather a synchronous thenable. We could also call it something other than .then to make this clearer. I'm just brainstorming.
Without a doubt we'll support hydrating both inside and outside of render! How we do that and how we best communicate it in docs and examples is very much up for debate though.

Note: render in this entire comment should actually be hydrate when server rendering.. This made me realize calling the API in React Query just hydrate as well is.. not good. hydrateCache makes a lot more sense, I'll change that!

Just to clear up what seems to be a misunderstanding, we aren't imposing that, the API you are asking for is already included in this PR!

Right 😅. I'm slowly getting onto the same page.

Queries should never be stale or garbage collected before the first render

Ah right yep that makes sense.
I'm curious, what would be the result of never querying initQueries? cache timeouts are never set so cache items hydrated from SSR are never invalidated?
I can see why it would be a good idea to perform the second step of hydration during the render as a side-effect 🤔. It sounds like what I would want then is something that allows me to hydrateCache outside of react and then initQueries inside of react. I'm not quite sure if the following is a good idea/API but I'm going to throw it out there anyway:
import React from "react";
import { hydrate } from "react-dom";
import { makeQueryCache } from "react-query";
import { hydrateCache } from "react-query/hydrate";

const queryCache = makeQueryCache();

// HydratedQueryInvalidator is probably not a great name but it's my
// attempt to think of a name that will communicate to consumers the
// reason they they have to render it into their component tree
// (presuming what I assume in my question above is accurate)
const { HydratedQueryInvalidator } = hydrateCache(queryCache, window.__QUERIES__);
// const { QueryInvalidation } = hydrateCache(queryCache, window.__QUERIES__);
// const { HydrationInvalidator } = hydrateCache(queryCache, window.__QUERIES__);
// const { HydrateFreshness } = hydrateCache(queryCache, window.__QUERIES__);
// const { HydrateStaleness } = hydrateCache(queryCache, window.__QUERIES__);

hydrate(
  <ReactQueryCacheProvider cache={queryCache} />
     <HydratedQueryInvalidator />
     <App />
  </ReactQueryCacheProvider>
)

Maybe hydrateCache could provide multiple options as ways to run the initQueries(); maybe an option to call a function or a component to render into your component tree. (As a side note did find the naming of initQueries slightly confusing, it isn't/wasn't clear to me why/what needs to be initialized).
const { initQueries } = hydrateCache(queryCache, window.__QUERIES__);
// maybe a different name?
initQueries()

// OR

const { HydrationInvalidator } = hydrateCache(queryCache, window.__QUERIES__);;
<HydrationInvalidator />

Looks like this is going to need to be updated for the new types :)

I've already talked to Tanner about this, but I wanted to update the PR as well for anyone following along. I'm back from vacations and plan to work on this for three full days during next week to hopefully finish it up! That includes refactoring to TS, docs and some extra functionality to better support dehydration/rehydration to/from localstorage.
This should have no breaking changes, so should be able to land it in a minor before v3.

This PR is starting to come together and I think only API-docs are missing which I'll work on today. I've updated the description to reflect the current state of things, here are the latest changes:

Basing the stale timeout on updatedAt and refactoring how timeouts work was moved to #917 which has been merged
Refactored the PR to TS (I really need help reviewing the types, I'm not a TS-expert, but they do pass, maybe @boschni wants to take a look?)
Added a bunch of new SSR integration tests around hydration
Removed dehydrateQuery from the public API
hydrate now schedules timeouts by default to be less confusing, but supports a activateTimeoutsManually-option for low level use (for example in useHydrate) (ping @pseudo-su)
dehydrate and hydrate now takes optional config-objects, most notably supporting shouldDehydrate and shouldHydrate filter-functions

There is an interesting caveat with the current API that I want to shine some extra light on, namely that only successful queries are dehydrated (ping @boschni). This has some consequences for SSR:

Any errors that happen on the serverside will show up as loading and be retried automatically on the client
To avoid React hydration mismatches when the above happens, you need to have a separate queryCache for prefetching and for rendering on the server and dehydrate between them before rendering.

This sounds funky, but the actual patterns aren't that weird when you look at them (check out the Next example in the description, that one works for example, or look at the SSR hydration integration tests). This is a potential footgun that needs to be highlighted in docs though and can be somewhat mitigated by recommending useHydrate over hydrate.

When you want to avoid a retry on the client or set a correct status code on the server because some critical piece of data failed, you want to pass throwOnError: true to the queryCache.prefetchQuery-function and handle that manually

API-docs and a new SSR-guide is done, I think this is ready for review now!
This should be fully backwards compatible and not introduce any bugs in existing functionality. Hydration is nuanced, so there might very well be edge cases I've missed thinking about, but I'm pretty confident in this as a first version.
What I'm not super confident about is the TS-typings, and the build setup could use a careful review too since having a new entry-point is a first for the library. And of course just the design overall.. 😅

Looking good! The need for separate caches when server side rendering does sound a bit confusing. Would be nice if there is a way to make both the server side and the client side straightforward to use. Think something like this would be the ideal way of working?
// Server
const cache = makeQueryCache()
cache.prefetchQuery('key', fn)
const state = dehydrate(cache)
const html = ReactDOM.renderToString(
  <ReactQueryCacheProvider queryCache={cache}>
    <App />
  </ReactQueryCacheProvider>
)
res.send(`
<html>
  <body>
    <div id="app">${html}</div>
    <script>window.__STATE__ = ${JSON.stringify(state)};</script>
  </body>
</html>
`)

// Client
const cache = makeQueryCache()
const state = JSON.parse(window.__STATE__)
hydrate(cache, state)
ReactDOM.hydrate(
  <ReactQueryCacheProvider queryCache={cache}>
    <App />
  </ReactQueryCacheProvider>
)

The main issue here is that if timers start when hydrating the cache, then the render could end up to be different between the server and the client. But maybe there are ways around that? The cache timer should not really matter because this is most likely in the range of minutes and queries do not GC immediately anymore. The one that is most important is the stale time, which I think is only relevant when there are actual observers. If the stale timer would only start when observers subscribe (which happens in a useEffect) then I guess the first render should be the same?

@boschni Thanks for checking it out!
I do agree it's a bit cumbersome in some setups and your example was the original plan. Not dehydrating errors really messes with using the same cache for prefetching and rendering on the server though, since to implement that we would have to have a separate "mode" somehow that doesn't persist errors to the cache. Not only would this have to be implemented in the core package which breaks separation of concerns, it is confusing to users in its own right.
Say we add a excludeErrors to prefetchQuery for example that you always need to call if you intend to dehydrate, or if you need to configure the queryCache itself for that when you create it? What about when you want to persist to localstorage? In that case you want the errors in the cache, but not dehydrate them.
Dehydrating the errors too would be another approach, but this is hard since errors are usually not vanilla JS and therefor hard to serialize (or at least hydrate on the other end).
So I ended up with the thinking that the current version is the lesser of two evils. This also creates an interface where we can have other logic in the future without causing mismatches, say for example that we set the default staleTime to a higher amount for dehydrated queries in the future? Ensuring queries on the server and the client go through the same process of dehydration before rendering also creates future opportunities.
About hydrate vs useHydrate, using hydrate the way you are using it in the example works and is safe. If you add some async process between that call and render however, that can break unless you add activateTimeoutsManually: true, so that is one reason I'm pushing useHydrate as the preferred API. The other reason is that pushing that hydration into the React tree, that encourages a pattern where the above problem of having separate caches for prefetching and rendering on the server becomes less of a problem and more part of the pattern. :)
If we look at a snippet from the SSR integration-tests:
    const serverPrefetchCache = makeQueryCache()
    await serverPrefetchCache.prefetchQuery('success', () =>
      fetchDataSuccess('success')
    )
    const dehydratedQueriesServer = dehydrate(serverPrefetchCache)
    const markup = ReactDOMServer.renderToString(
      <ReactQueryCacheProvider>
        <Page dehydratedQueries={dehydratedQueriesServer} />
      </ReactQueryCacheProvider>
    )

I think needing two separate caches for prefetching and rendering is troublesome on paper (and somewhat in practice), but when looking at the code like this, it's kind of hidden away by the fact that <ReactQueryCacheProvider> creates the render-cache for you behind the scenes. :)
So I totally agree this is a pain point, but the alternatives have some tradeoffs I considered to be worse.
About activating timeouts only in a useBaseQuery effect, this would work if all queries that you prefetch on the server were actually used on first render, but a valid pattern is also to prefetch some queries on the server where the latency is low and de/rehydrate it, but not rendering the corresponding React components until lazily on the client. Those would end up never getting scheduled for staleness or GC unless they were actually rendered at some point.

Now that I can see it on paper, I really do prefer @boschni's first suggested syntax: https://github.com/tannerlinsley/react-query/pull/728#issuecomment-680104238

@tannerlinsley Well, I do too, but it doesn't work. It will lead to hydration mismatch on errors unless:

We dehydrate errors too (which I don't know how to solve)
We introduce something like this:

// Server
const cache = makeQueryCache()
cache.prefetchQuery('key', fn, { ejectQueryFromCacheOnError: true }) // <-- This is new
const state = dehydrate(cache)
const html = ReactDOM.renderToString(
  <ReactQueryCacheProvider queryCache={cache}>
    <App />
  </ReactQueryCacheProvider>
)
res.send(`...`)

ejectQueryFromCacheOnError could be named better of course, but either way, this would be required to avoid hydration mismatches. Another approach could be to re-introduce the concept of makeServerQueryCache with slightly separate behaviour from makeQueryCache (not saving errors). This was in my first PR, but you wanted this contained in a separate entry point.. 😅
To guarantee that the cache we are rendering with on the server and the client are the same and doesn't cause React hydration mismatches on error, we somehow need to remove queries that error out on the server or solve de/rehydration of them (which also has an effect on UX that we would need to discuss). Doing this by using the same dehydrate-interface in both places still seems like the lesser evil to me.
I still agree this is a pain point and I'm very open to suggestions on how to solve this.

Btw, none of this has any bearing on Next.js btw, there you have to use a separate cache for prefetching and rendering on the server anyway, so whatever extra API we introduce to solve this for some custom SSR cases will probably be an unnecessary extra burden there.

The serialization part is indeed interesting as both the query results and errors could contain JSON incompatible values. GraphQL does not have this issue because all values are JSON compatible and Redux stores could have this issue but it is generally recommended to only have JSON compatible values in the store. There are a few options how we could deal with this:

Require users to make sure their results and errors are JSON compatible when using SSR.
Provide a query option to automatically serialize results and errors before storing them in the query state.
Provide the possibility to serialize and deserialize non-JSON compatible values in results and errors when hydrating and dehydrating. This could be done by providing a serialize function to hydrate and a deserialize function to dehydrate (personally I like this one most).

As for sending queries to the client which are not rendered: I think these don't need to have a stale timeout as this only makes sense for queries which are being observed. The GC timeout could always be set (even on query creation) because this will most likely only trigger after a few minutes?

Yes, I like the sound of that.

Assume that all store values are JSON compatible. 99% of people are probably already doing this regardless of SSR. If they are using SSR, they don't really have any other choice (even with Next)
Dehydrate and hydrate errors (probably even reinstantiate the err eg. new Error(serializedError) on hydration). This is one that might change over time, but as long as we do the following 👇 , we'll leave ourselves plenty of room to improve
Provide dehydrate({serialize}) and hydrate({deserialize}) callbacks with sane defaults
Simplify the API as discussed above

I have thought along those lines as well, but decided to leave custom serialization out in this initial PR for a couple of reasons, which I'd love to talk through.
First of all, we should consider what we want the default UX to look like. Should we present loading states to the users and refetch queries that had errors by default, or should we show the errors by default? My thinking has been that refetching those on the client is a sane default as a means of trying to recover, especially since a lot of SSR is cached for a period of time. I'm not at all certain if this is the best approach, but since this affects UX I think it's something we should consider first. (We always need a way to opt out of course)

Assume that all store values are JSON compatible. 99% of people are probably already doing this regardless of SSR. If they are using SSR, they don't really have any other choice (even with Next)

I absolutely agree with this when it comes to data, but from the examples I've seen, people aren't really doing that or dehydrating/rehydrating errors today. Consider the approach in the docs right now, it only talks about initialData. Often with Next or Redux, people aren't really saving the errors themselves in a store or de/rehydrating them, only the error state, but with React Query this isn't really true since it saves the actual error in the cache by default.
A thing to consider here is that a lot of errors can come from node/the network layer. I think a lot of default errors that users have not introduced themselves can easily propagate through into the cache? Some of these might not exist on the client and therefor not be truly deserializeable. Users would have to catch every single error and convert them into something serializable.
Even with sane defaults (which I'm not sure how or if we could implement well), I think requiring custom serialization/deserialization is a huge burden to add to even get up and running, compared to the API in this PR, slightly awkward as it might be for custom SSR setups.
I think what I'm arguing is that both for users and developers, only dehydrating successful queries might be a good default?
Either way, I agree we should add support for custom serializers and deserializers and an option to include errors when dehydrating. For personal reasons I don't think I can find time to implement that in the next month or so because I will be mostly afk, it was a stretch getting this PR together in time. If this is a blocker for the PR I would love it if someone else could take over that part, if not, I would love it if we made that part of a follow up.
Also, this is still an early API, we can also tweak things that doesn't work well in the v3 release?

Oh and if it's the useHydrate itself that is awkward, does introducing a <ReactQueryHydrator queries={dehydratedQueries}> help with that? I kind of think it does in the custom SSR case, and having a declarative API for it makes it a bit clearer that it's the app itself that needs a set of dehydratedQueries to render properly?
Activation of timeouts

As for sending queries to the client which are not rendered: I think these don't need to have a stale timeout as this only makes sense for queries which are being observed. The GC timeout could always be set (even on query creation) because this will most likely only trigger after a few minutes?

This is a good point! So is your suggestion then to remove the activateTimeoutsManually and activateTimeouts entirely from the public API, do that automatically behind the scenes for GC in hydrate and just let the useBaseQuery activate the staleness? Would require some reshuffling of the earlier refactor in query, but should be simple enough.

I'm 100% on board with just skipping (and not dehydrating failed queries) by default. And I'm even okay not offering a way to do that until it comes up as a strong use case (if ever)/

As for the useHydrate API, I  personally don't like it, nor do I want to add another API. I would rather just have it be:
const cache = makeQueryCache()
const state = JSON.parse(window.__STATE__)
hydrate(cache, state)
ReactDOM.hydrate(
  <ReactQueryCacheProvider queryCache={cache}>
    <App />
  </ReactQueryCacheProvider>
)

And whatever we need to do to get to that point, I'm willing discuss. Keeping the API surface area the same size if possible is my intuition here.

I agree, but for Next we don't have control over the app at that point in time, so we sadly need to do it in render somehow for that case. :( This is a big whole in the API of Next in my opinion, a lot of examples for how to integrate Redux and other libraries are pretty ugly because of this too.
 Because we need it anyway I decided to kind of embrace it for custom SSR as well to document a single consistent way of doing it instead of trying to explain when to use what if that makes sense?

Also, if you don't want to use useHydrate on the server with custom SSR, you can also do this, but I think it looks a bit wonky which is another reason I've recommended the useHydrate-approach:
// Prefetch
const prefetchCache = makeQueryCache()
prefetchCache.prefetchQuery('key', fn)
const state = dehydrate(prefetchCache)

// Render
const renderCache = makeQueryCache()
hydrate(renderCache, state)
const html = ReactDOM.renderToString(
  <ReactQueryCacheProvider queryCache={renderCache}>
    <App />
  </ReactQueryCacheProvider>
)
res.send(`...`)

Timers
Yes exactly! I think we can just schedule the GC in the query constructor as previously because this would be in the order of minutes. And if we schedule the stale timeout only whenever an observer subscribes, then there shouldn’t be any timing issues?
Errors serialization
While it is indeed true that there are a lot of different type of errors which could occur, only the ones that the user is actually handling in the UI are relevant. Which means the user should know exactly which errors could affect the UI. Which also means they should be able to write a serializer for it.
The serialization and deserialization could be done like this:
function dehydrate(cache, config) {
  const state = JSON.parse(JSON.stringify(cache.queries, config.serialize))
}

function hydrate(cache, state, config) {
  const queries = JSON.parse(state, config.deserialize)
}

dehydrate(cache, {
  serialize: (_key, value) => {
    if (value instanceof Error) {
      return { $type: "Error", message: value.message }
    }
    return value
  }
})

hydrate(cache, state, {
  deserialize: (_key, value) => {
    if (value?.$type === 'Error') {
      return new Error(value.message)
    }
    return value
  }
})

Or someone could choose to handle this without serialization in the query functions:

useQuery('key', async () => {
  try {
    return await api()
  } catch (error) {
    if (error instanceof Error) {
      throw error.message
    }
    throw error
  }
})

Removing failed queries
Could this be an option if someone wanted to do that?
const cache = makeQueryCache()
cache.prefetchQuery('key', fn)
cache.removeQueries(query => query.state.isError)
const state = dehydrate(cache)
const html = ReactDOM.renderToString(
  <ReactQueryCacheProvider queryCache={cache}>
    <App />
  </ReactQueryCacheProvider>
)

Timers
Purely code-wise I still think we should keep the scheduling out of the constructor for different reasons unrelated to this PR, but I do agree we could and should schedule GC immediately on hydrate and let the observer schedule staleness which lets us remove the whole activateTimeoutsManually thing. I've updated the PR with this!

Error serialization
I talked to Tanner about this at length yesterday and we discussed very similar APIs to that. It took me a good nights sleep to realize that this isn't even a problem for React Query at all!
I even wrote this in the documentation yesterday:

This result is not in serialized form, you need to do that yourself if desired

So since dehydrate returns an un-serialized form, serialization is a user-level concern, not a framework one. So what's left to discuss is if we should include errors or not by default, and how to let the user toggle that.
I still think we should remove errors by default because I think that should be the majority use case, and the alternative requires a bunch of work on the users part. When it comes to how to toggle this we discussed a includeErrors: true-option yesterday, but now I realized that shouldDehydrate already covers this use case!
I've pushed an update that does this:

Instead of having a hardcoded query.state.status === 'success' in dehydrate, this has been moved to be a default shouldDehydrate-function
If you want to include all queries, provide your own shouldDehydrate: () => true or shouldDehydrate: query => query.state.status !== 'loading' if you want to exclude loading

@Ephem This is a killer release, not to mention 0 breaking changes. Thank you much!!

Getting there!
GC
It might be good to active the GC timer in the constructor though, because if for some reason the timer is not activated, it'll stay in the cache forever. Although preferably the QueryCache would be responsible of GC instead of the Query itself.
Serialization
While I definitely agree the actual (de)serialization should be the responsibility of the user, I do think it would be nice if we would provide an easy and straightforward way for them to do so.
Query filtering
Would it be possible to only have one cache on the server? Similar to the example in https://github.com/tannerlinsley/react-query/pull/728#issuecomment-680697850 ?
useHydrate
Is this hook still needed?

GC
Yeah, we need to make sure to always schedule this internally. There is a caveat around prefetching that makes me want to avoid doing it in the constructor that I can explain elsewhere, but in its current form this is all internal implementation details and we can tweak this after the PR. Okay if we move this discussion elsewhere?
Serialization
I agree! We can always add custom JSON.stringify-replacers to the library in the future.
New hydration/ReactQueryCacheProvider
This hopefully addresses both your points about filtering and useHydrate at the same time. 😄  Yes, we do need useHydrate and/or some other way to ergonomically hydrate inside of render because of how Next works. In Next, we only have access to the dehydrated queries via props, which we only have access to in render.
Tanner came up with the idea of adding a new ReactQueryCacheProvider that you can import directly from the hydration entrypoint. This one has two additional props to the one you can import from the core package:

initialQueries
hydrationConfig

So instead of exposing a <Hydrator />-component, we bake that into CacheProvider instead. This means your custom SSR-example would become:
// Server
const prefetchCache = makeQueryCache()
await prefetchCache.prefetchQuery('key', fn)
const initialQueries = dehydrate(prefetchCache)

const html = ReactDOM.renderToString(
  <ReactQueryCacheProvider initialQueries={initialQueries}>
    <App />
  </ReactQueryCacheProvider>
)
res.send(`
<html>
  <body>
    <div id="app">${html}</div>
    <script>window.__REACT_QUERY_INITIAL_QUERIES__ = ${JSON.stringify(initialQueries)};</script>
  </body>
</html>
`)

// Client
const initialQueries = JSON.parse(window.__REACT_QUERY_INITIAL_QUERIES__)
ReactDOM.hydrate(
  <ReactQueryCacheProvider initialQueries={initialQueries}>
    <App />
  </ReactQueryCacheProvider>
)

(I've also updated the Next example in the PR description)
Hopefully this looks okay? I'm open to adding a more generic queryCache.filter-function in the future that would when used right let you use the same cache on the server, but I don't think that should be the recommended approach mostly because I want to recommend a single way of doing it for Next and custom SSR.
I've pushed the hydration/ReactQueryCacheProvider as well as new docs.
@tannerlinsley This PR should now be up to date with what we talked about yesterday, but with the addition that you can now include errors in dehydration by using shouldDehydrate: () => true 🎉  (see comment above). I've also added the initialData-approach back to the docs.

Thanks for the excellent comments, they have really helped improve this PR! From my point of view this is ready now.

:tada: This PR is included in version 2.13.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add adbmanager methods

While working on a new Step for running tests without building for Android builds, I introduced some new methods that use the adb binary. Rather than keep those methods sequestered in the new Step, @godrei and I decided it would be worth putting them in this shared library for others to use.
Version
I believe a minor version bump would be appropriate for this, as it's only an addition.
Changes

Transitioned most of the usages of the go-utils/command package to use the new v2 version. (See the Decisions section below for some more context on this.)
Deleted the vendor directory, as that is the current standard for our libraries.
Added new adb methods to adbmanager.go.

Decisions
When I originally wrote the adb methods, I wrote them within the new Step, and used the v2 version of go-utils' command package. Rather than rewrite the new methods to use the older version of command, I thought it would be better to update this library to use the new version of command.
Note: Some of these changes were based off of similar changes from @godrei in the adbmanager branch of this repo (https://github.com/bitrise-io/go-android/pull/48).

@godrei I see there's a v1 branch for this library. Do I need to add these changes to the v1 branch as well?


Fix message displayed when failing to add a Patient

The message displayed when the patient added by the user already exists in the list sometimes includes the wrong role for that person.
Let's update the error message.

LGTM


Suggestion: supporting asynchronous stack traces for async/await in TypeScript

Background
Currently TypeScript supports the async and await keywords when ES6 is set as build target, using generators under the hood. This is a promising feature as it allows you to write synchronous looking code that is much easier to write and understand than in a traditional callback based approach. Take for instance this code.
function sleep(time) {
    return new Promise(function (resolve) {
        setTimeout(resolve, time);
    });
}

async function fun1() {
    console.log('Step 1');
    await sleep(500);
    console.log('Step 2');
    await sleep(500);
    const ret = await fun2();
    console.log(`Done in ${ret} steps`);
}

async function fun2() {
    console.log('Step 3');
    await sleep(500);
    return 3;
}

function main() {
    fun1().then(() => {
        console.log('Finished program');
    }).catch((err) => {
        console.error(err.stack);
    })
}
main();

Being able to write code in this way is a big step toward making node.js a comfortable and productive platform for writing server applications. Unfortunately, there is a catch, that really is not something new with generators, but anyway that destroys all the productivity you may hoped to get from this feature: Neither node.js or TypeScript implement asynchronous stack traces on exceptions (also known as long stack traces).
As a consequence, if you edit fun2() like this, making it fail in an obvious way...
async function fun2() {
    throw new Error('miau');
}

You will get this error on runtime:
Error: foo error
    at /tmp/untitled/main.js:26:15
    at next (native)
    at /tmp/untitled/main.js:6:65
    at __awaiter (/tmp/untitled/main.js:2:12)
    at fun2 (/tmp/untitled/main.js:25:12)
    at /tmp/untitled/main.js:20:27
    at next (native)
    at fulfilled (/tmp/untitled/main.js:3:58)

Not a single trace of fun1, which was the actual fun2 caller. It's not hard to guess what this means in codebases larger than this extremely short example: hours of console.log() calls in every piece of code that may be even remotely related to the error, frustration and finally anger when the source of the error is found, which more often than not is a trivial error on the caller function. Then you wonder how so many people are using node.js for writing web applications and what's wrong with them, suffering in this way.
Existing solutions: Bluebird
This issue is not new and fortunately a few people have actually tried to tackle it down. For instance, the promise library bluebird includes support for long stack traces: chained promises get the stack trace of the previous promise, which is added to error traces if a rejection happens.
Here is some code very similar to the TypeScript/ES6 async/await example before, but using Promise.coroutine() from Bluebird:
const Promise = require('bluebird');
Promise.config({
    longStackTraces: true
});

function sleep(time) {
    return new Promise(function (resolve) {
        setTimeout(resolve, time);
    });
}

fun1 = Promise.coroutine(fun1);
function* fun1() {
    console.log('Step 1');
    yield sleep(500);
    console.log('Step 2');
    yield sleep(500);
    const ret = yield fun2();
    console.log("Done in " + ret + " steps");
}

fun2 = Promise.coroutine(fun2);
function* fun2() {
    throw new Error('foo error');
}

function main() {
    fun1().then(() => {
        console.log('Finished program');
    }).catch((err) => {
        console.error(err.stack);
    });
}
main();

It generates this stack trace, which is relatively compact and definitively useful:
Error: foo error
    at fun2 (/tmp/untitled/test-bluebird.js:24:11)
    at next (native)
From previous event:
    at fun1 (/tmp/untitled/test-bluebird.js:18:23)
    at next (native)
    at tryOnImmediate (timers.js:534:15)
    at processImmediate [as _immediateCallback] (timers.js:514:5)
From previous event:
    at main (/tmp/untitled/test-bluebird.js:28:5)
    at Object.<anonymous> (/tmp/untitled/test-bluebird.js:34:1)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:146:18)
    at node.js:404:3

Bluebird gotchas
Everything is awesome and beautiful until you mix some old school callback code there...
function halfBakedPromiser() {
    return new Promise(function promiseResolver(resolve) {
        setTimeout(function timeoutCallback() {
            throw new Error('callback error');
        }, 100);
    })
}

fun2 = Promise.coroutine(fun2);
function* fun2() {
    yield halfBakedPromiser();
}

and suddenly no traceback (well, technically it's still a traceback, but it's almost useless):
/tmp/untitled/test-bluebird.js:25
            throw new Error('callback error');
            ^

Error: callback error
    at timeoutCallback [as _onTimeout] (/tmp/untitled/test-bluebird.js:25:19)
    at Timer.listOnTimeout (timers.js:92:15)

... or even promises made with another library, including ES6 native promises.
function foreignPromiser() {
    return new global.Promise(function promiseResolver(resolve) {
        setTimeout(resolve, 100);
    }).then(function thenResolver() {
        throw new Error('other promise error');
    });
}

fun2 = Promise.coroutine(fun2);
function* fun2() {
    yield foreignPromiser();
}

In this case the trace still preserves the information from previous Bluebird promises but the last one. That one has gone missing since setTimeout was called by the native Promise constructor.
Error: other promise error
    at thenResolver (/tmp/untitled/test-bluebird.js:26:15)
From previous event:
    at fun1 (/tmp/untitled/test-bluebird.js:18:23)
    at next (native)
    at processImmediate [as _immediateCallback] (timers.js:383:17)
From previous event:
    at main (/tmp/untitled/test-bluebird.js:36:5)
    at Object.<anonymous> (/tmp/untitled/test-bluebird.js:42:1)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:141:18)
    at node.js:933:3

So far Bluebird is a good solution for tracing asynchronous code as long as you always do all asynchronous work inside a promise and don't mix other promise libraries. Fortunately the A+ standard exists to make them replaceable to some extent and many libraries allow changing their promise constructor.
Other solutions
Longjohn
There are other approaches to tackle this problem. For instance, longjohn hooks node.js EventEmitter in order to save stack traces the instant asynchronous actions are queued and wraps the callbacks in order to recover the previous traces in case of an error.
longjohn is very useful to tackle down the source of errors for dangling callbacks like in the case of halfBakedPromiser() before. It's not very adequate to use plain callbacks relying in longjohn as the error catcher though, as it just modifies the stack property of the error when it escapes the callback and then rethrows it. After that the process dies, killing all active connections in the case of a server (long lived ones e.g. WebSocket included) unless some sort of deprecated hack like node domains is used.
longjohn is not able to improve the reporting for foreignPromise() and shows an even less useful output if Bluebird long stack traces are disabled.
For well behaved promises, when used alone (with longStackTraces: false set in Bluebird) longjohn is also able to show a useful traceback. It's different than the one generated by Bluebird in that the same asynchronous function/generator call may appear more than once, once for each time it yielded.
When used with longStackTraces: true, longjohn conflicts a bit with bluebird, since both add calls to the stack on their own way. longjohn calls appear at the end, after startup (node.js). In consequence, the generated call list is a bit weird since it actually goes down, up and down again.
Asynchronous stack frames (Chrome only)
Chrome debugger has recently implemented support for asynchronous stack traces. This works similarly to longjohn in that it follows code through asynchronous boundaries, but allows full inspecting of the value of the variables in previous frames too. This feature is only enabled when the developer tools are open, so it's not possible to get this enriched stack trace in application code (e.g. to send an automatic bug report).

Proposal
Since there are many ways in which asynchronous code may be structured in an application in order to make error processing and debugging manageable at large scale it may be desirable to be able to adapt TypeScript output code to them when the async/await keywords are used.
At the moment TypeScript always emits a polyfill like this in all files using async...
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator.throw(value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments)).next());
    });
};

... with functions like this ...
async function fun1() {
    await sleep(500);
}

... being turned into:
function fun1() {
    return __awaiter(this, void 0, void 0, function* () {
        yield sleep(500);
    });
}

A user may want to replace it with a Promise.coroutine implementation in order to get sane tracebacks when debugging, like this:
var __PromiseBluebird = require('bluebird');
var __awaiter = function (thisArg, _arguments, P, generator) {
    return __PromiseBluebird.coroutine(generator).apply(thisArg, _arguments);
};

Or they may even want to remove the __awaiter altogether in order to avoid it popping on the stack trace and avoid creating unecessary closures. In that case this output would be preferred:
fun1 = __PromiseBluebird.coroutine(fun1);
function* fun1() {
    yield sleep(500);
});

Replacing the awaiter polyfill could be done quite simply with the tsconfig.json. For instance, a new optional property awaiterPolyfillDefinition would store a path relative from the TypeScript project root pointing to a .js file with the new polyfill.
Replacing the how the async functions are emitted as JavaScript code in order to remove the __awaiter call may be harder on the other hand due to hoisting. The .coroutine() call would have to be hoisted above any usage of the function or otherwise it would be called as a generator instead of as a promise returning function, causing a runtime error.

It is already possible to replace the implementation of __awaiter in TypeScript, as in your example above:

var __PromiseBluebird = require('bluebird');
var __awaiter = function (thisArg, _arguments, P, generator) {
return __PromiseBluebird.coroutine(generator).apply(thisArg, _arguments);
};

We do plan to have some broad support for loading helpers from an external helpers library in the future, though nothing quite so granular as you are proposing with `awaiterPolyfillDefinition`.

@rbuckton Do you mean explicitly overwriting __awaiter? Like:
async function foo() {
  await foo();
  return 10;
}

function __awaiter() {
// ...
}

@hayeah, yes.

Adding code at the top to replace __awaiter works, but it's a bit error prone since you need to do it for each file -- failure to do so will cause competing implementations and generates more code than really necessary.

Adding code at the top to replace __awaiter works, but it's a bit error prone since you need to do it for each file -- failure to do so will cause competing implementations and generates more code than really necessary.

Currently you can provide noEmitHelpers as a compiler flag and provide your helpers some other way.  The team are working on making that more maintainable in the future (see #3364).

Unfortunately I've found replacing __awaiter code to create a Bluebird coroutine and immediately call it not only is inefficient, but also it does not produce async stack traces when there are nested calls. :disappointed:
The following test case shows it failing:
const Promise = require('bluebird');
Promise.config({
  longStackTraces: true
});

function __awaiter(generator) {
  return Promise.coroutine(generator)();
}

function sleep(time) {
  return new Promise(function (resolve) {
    setTimeout(resolve, time);
  });
}

function fun1() {
  return __awaiter(function* fun1_cor() {
    console.log('Doing work...');
    yield sleep(50);
    const ret = yield fun2();
    console.log("Done in " + ret + " steps");
  })
}

function fun2() {
  return __awaiter(function* fun2_cor () {
    throw new Error('foo error');
  })
}

function main() {
  fun1().then(() => {
    console.log('Finished program');
  }).catch((err) => {
    console.error(err.stack);
  });
}
main();

It produces this stack trace, where line 20 (const ret = yield fun2();) cannot be found.
Doing work...
Error: foo error
    at fun2_cor (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:27:11)
    at next (native)
From previous event:
    at __awaiter (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:7:38)
    at fun1 (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:17:10)
    at main (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:32:3)
    at Object.<anonymous> (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:38:1)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:141:18)
    at node.js:933:3

On the other hand, creating them in __awaiter and calling them in the outer function works, but it would be even better to only create the coroutines once, like this:
const Promise = require('bluebird');
Promise.config({
  longStackTraces: true
});

function __async_gen(generator) {
  return Promise.coroutine(generator);
}

function sleep(time) {
  return new Promise(function (resolve) {
    setTimeout(resolve, time);
  });
}

const fun1 = __async_gen(function* fun1() {
  console.log('Doing work...');
  yield sleep(50);
  const ret = yield fun2();
  console.log("Done in " + ret + " steps");
});

const fun2 = __async_gen(function* fun2 () {
  throw new Error('foo error');
});

function main() {
  fun1().then(() => {
    console.log('Finished program');
  }).catch((err) => {
    console.error(err.stack);
  });
}
main();

This way is not only more efficient, but also produces cleaner, complete tracebacks:
Doing work...
Error: foo error
    at fun2 (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:24:9)
    at next (native)
From previous event:
    at fun1 (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:19:21)
    at next (native)
    at processImmediate [as _immediateCallback] (timers.js:383:17)
From previous event:
    at main (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:28:3)
    at Object.<anonymous> (/home/ntrrgc/tmp/untitled3/untitled/testcase.js:34:1)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:141:18)
    at node.js:933:3

The only nuisance with that is that it breaks hoisting, unless it would be handled by TypeScript.

Promise.coroutine is meant to be called once per function. Calling it per invocation is very slow.


Address Book Using Javascript

Hi ! I am Aliya Rahmani, a GSSOC'21 participant.
I would like to work on an Address Book management system developed by javascript, HTML, CSS. In this javascript project has a Name, Address, Telephone number, Email, website for the Address Book management system. If any information is incorrect, there are buttons to correct and delete.
Please , kindly assign this task to me

@aliya-rahmani Sounds Good. Go Ahead

@991rajat  thanks for assigning

@aliya-rahmani Any update?, Kindly reply within 2 days or I have to close it.


The zoom behavior doesn't get applied if the user specified disableMouseZoom

Adds an options for the user to disable mouse zooming functionality, giving the scroll wheel back to the browser window.
Downside: This is currently an option that can’t be turned back on without destroying and recreating the map.

Looks good, thanks!


RATIS-1144. Default disable datastream when start a MiniRaftCluster

What changes were proposed in this pull request?
Default disable datastream when start a MiniRaftCluster, so that the other test no need to start data stream server, to make the CI run faster.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/RATIS-1144
How was this patch tested?
no need to add new ut.

+1


New users unable to login the first time after redeeming Azure AD invite (msal.interaction_status=inProgress)

Library
<EMAIL_ADDRESS>Framework
Angular v8
Description
We allow users to sign-up for a new user account in Azure AD using an e-mail invite. When the user completes the invite flow in the same browser window as they have our application open in the user is unable to sign-in.
When we call the loginRedirect method the user is immediately redirected back to our application and in localStorage we see that the msal.interaction_status is inProgress.
This only happens when the user completes the Azure AD invitation flow in the same browser window.

Security
No
Regression
No, before (msal 1.1.x) we got invalid state "null". See this issue: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/960
Configuration
var msalConfig: Msal.Configuration = {
      auth: {
        clientId: environment.adClientId,
        authority: this.authority,
        redirectUri: environment.authRedirectUrl,
        validateAuthority: true,
        postLogoutRedirectUri: environment.authRedirectUrl
      },
      cache: {
        cacheLocation: "localStorage"
      }
    };

Reproduction steps

Create a new user
Open the redeem invite link (from Azure AD e-mail) in the same browser window
Complete the registration
Login to our application

Workaround
I discovered that either closing the browser window and opening a new one or signing the user out using the logout() method in the SDK allows the user to log in afterward.
Clearing local storage, session storage and/or cookies does not help.
Expected behavior
I would expect the new user to be signed in to our application after clicking login without having to specify his/her username and password because they are already signed into Azure AD as part of the invite flow
Browsers
No

@pkanher617  do you know what this could be caused by?

@sanderaernouts Have you found workaround?

@vadimblv yes, we detect that login is in progress using app.getLoginInProgress(), show a model with an error message and then invoke app.logOut when the user dismisses the modal.
The behavior is a bit strange because the user tries to log in, fails, and is then forced to logout and try again. But, in our case, it does get the user out of this situation.

@DarylThayil @pkanher617 any ideas what is causing this? As mentioned in my previous comment we do have a workaround but it feels like a last resort and is not really a good user experience :(

Sorry just to refresh this, is the problem that application state (local storage) is not taking into account that the user is already logged in with the identity provider or is the problem that the identity provider is no aware the user is logged in?

@pkanher617  pinging this could this be a case where inProgress in not turned off because of a special login case returning a different hash?

Sorry just to refresh this, is the problem that application state (local storage) is not taking into account that the user is already logged in with the identity provider or is the problem that the identity provider is no aware the user is logged in?

@DarylThayil the identity provider is not aware that the user is already logged in. Clearing the cache, local storage, and cookies does not help. If the user closes the browser and opens a new one then this problem does not occur anymore as far as I know.

@sanderaernouts Apologies for the delayed response on this issue. If you are still having this issue with the latest version of MSAL, could you please post a snippet of the code you are using to create the msal object and call loginRedirect?
I suspect this has something to do with the handleRedirectCallback function not being called, but I would need to see the code to be sure.


No pagination is avaliable for GOV.UK Frontend review application page

This issue is from a May 2019 external accessibility audit report.
WCAG Reference: Usability feedback only, there is no WCAG related guidelines.
Issue ID: DAC_Issue30
URL: http://govuk-frontend-v3.herokuapp.com/full-page-examples/news-and-communications?order=most-viewed
Page: News and communications
Screen Shot

The page tested stated that there were 822,411 results, however as these cannot be displayed on one page, a pagination feature should be present to allow users to navigate through the other pages of results. Analysts felt that more results must be available but
were unable to view them. Even with the filter options selected, that many results would not be lessened by enough to display on one page.
Screen reader comments

“No feature to enable me to view the next page of results was present on the page. This would mean in a non-testing environment that I was able to view the first page of results only. Implementing a pagination to enable me to view different pages would provide a more effective experience. This occurred using JAWS, NVDA and VoiceOver for iPhone and Mac.”

This review page is intentionally fake, so pagination would not really function as expected, we could consider adding one to make the example more realistic but might be more effort than needed here.
I've but awaiting-triage on this to make a decision on this, the priority is low since it's not an issue with GOV.UK Frontend.

Met with the developers and we have decided to close this given the time it'd take to update, and this is intentionally fake.


danger pr crashes with "undefined method `sha' for nil:NilClass (NoMethodError)"

Report
What did you do?
I ran this command, to try and debug locally a Dangerfile behavior on a given PR
$ DANGER_GITHUB_API_TOKEN=<mytoken> bundle exec danger pr "https://github.com/MyCompany/my-private-repo/pull/10879" --dangerfile=danger-ci/Dangerfile

What did you expect to happen?
Danger to locally run the rules in the Dangerfile using the metadata of the mentioned PR
What happened instead?
Crash with following backtrace:
Traceback (most recent call last):
  15: from /Users/me/.rvm/gems/ruby-2.6.4/bin/ruby_executable_hooks:24:in `<main>'
  14: from /Users/me/.rvm/gems/ruby-2.6.4/bin/ruby_executable_hooks:24:in `eval'
  13: from /Users/me/.rvm/gems/ruby-2.6.4/bin/danger:23:in `<main>'
  12: from /Users/me/.rvm/gems/ruby-2.6.4/bin/danger:23:in `load'
  11: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/bin/danger:5:in `<top (required)>'
  10: from /Users/me/.rvm/gems/ruby-2.6.4/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
   9: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/commands/pr.rb:60:in `run'
   8: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/commands/pr.rb:60:in `new'
   7: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/danger_core/environment_manager.rb:30:in `initialize'
   6: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/danger_core/environment_manager.rb:30:in `new'
   5: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/local_git_repo.rb:45:in `initialize'
   4: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/local_git_repo.rb:95:in `found_pull_request'
   3: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/support/pull_request_finder.rb:17:in `call'
   2: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/support/pull_request_finder.rb:31:in `check_if_any_pull_request!'
   1: from /Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/support/pull_request_finder.rb:52:in `pull_request'
/Users/me/.rvm/gems/ruby-2.6.4/gems/danger-6.3.1/lib/danger/ci_source/support/pull_request_finder.rb:83:in `generate_remote_pull_request': undefined method `sha' for nil:NilClass (NoMethodError)

The PR url is a copy/paste from the window open in my browser so it should be correct, the Pull request still exists and is still open, and both the base and head branches are still existing on the remote.
base branch name is of the form devname/sdk/feature1 and head branch name is on the form devname/sdk/feature1-part2
Your Environment

Which CI are you running on?
This was when attempting to run Danger locally, on a PR from our private GitHub repo. Using RVM with Ruby 2.6.4 locally.

Are you running the latest version of Danger?
Yes, just updated to 6.3.1

What is your Dangerfile?

Too long to paste here (it is even split in multiple files that we include using require_relative), and I don't think it's relevant to the problem because the crash happens before the Dangerfile is even interpreted, at the step where Danger tries to find the Pull Request reference to run its rules on.

Strange thing though: if I try to run what I believe is the set of ruby commands run by Danger internally, I get non-nil results though
$ pry                                                                                ‹ruby-2.6.4›
[1] pry(main)> require 'octokit'
=> true
[2] pry(main)> c = Octokit::Client.new(access_token: 'redacted', api_endpoint: 'https://api.github.com/')
=> #<Octokit::Client:0x00007ffd908d1ef0 ...>
[3] pry(main)> p = c.pull_request('Babylonpartners/babylon-ios',10879)
=> {:url=>"https://api.github.com/repos/babylonhealth/babylon-ios/pulls/10879",
 :id=>385688262,
…
}
[4] pry(main)> p.base.sha
=> "d1abe3839373a655ac0bb15f818d2dd274251121"
[5] pry(main)> p.head.sha
=> "3aa6b3c26e5a6ceec5b26d8a09fc3ab605c59d13"

When I instead add some puts in the source of Danger to debug the def remote_pull_request method in pull_request_finder.rb:91, the result of client.pull_request(repo_slug, specific_pull_request_id) is printed as #<Sawyer::Resource:0x00007faded1a9f08> and not as the huge Hash I see in pry. And then its .head and .base properties are indeed nil.

Ah! Found the issue: The repo has been moved to a new org a while ago (like, maybe 8 month ago).
For some reason I was still using the old repo_slug in my invocation to danger pr.

In pry that didn't seem to be a problem and Octokit was able to follow the redirect and return the proper metadata.
In Danger code itself though, adding a puts r.to_h to dump the result of r = client.pull_request(repo_slug, specific_pull_request_id) led to the following output:

{:message=>"Moved Permanently", :url=>"https://api.github.com/repositories/18095916/pulls/10879", :documentation_url=>"https://developer.github.com/v3/#http-redirects"}

Not sure why in pry it follows redirects but in Danger it doesn't. I think it would be nice to still fix this and enable the case of repo redirects when using Octokit from within Danger

Interesting, maybe there's some flag for this in OctoKit?

I think the version of octokit we've got set in the Gemfile.lock (4.16) should be following redirects by default. It relates to the 'accept' parameter on the client.pull_request call which defaults to default_media_type.
Ah - as long as we use the Octokit::Middleware::FollowRedirects middleware. I suspect we have a custom middleware stack sneaking in somewhere. Should be a relatively easy one :)


Publish the sdk in a public maven repository

I'm aware the sdk is in its early stages, but currently the only way to consume it requires cloning the git repository and installing it in a local maven repository. Once publicly available it would be easier to access and play with it.

FWIW the following POM elements must be defined before publishing to Maven Central:
$ mvn org.kordamp.maven:pomchecker-maven-plugin:1.2.0:check-maven-central
[INFO] Scanning for projects...
[INFO]
[INFO] -------------------< dev.cdevents:cdevents-sdk-java >-------------------
[INFO] Building cdevents-sdk-java 0.0.1
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- pomchecker-maven-plugin:1.2.0:check-maven-central (default-cli) @ cdevents-sdk-java ---
[WARNING] <url> is not defined in POM. Will use computed value from parent:
	null
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.281 s
[INFO] Finished at: 2022-08-02T20:17:45+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.kordamp.maven:pomchecker-maven-plugin:1.2.0:check-maven-central (default-cli) on project cdevents-sdk-java: MavenCentral check failed:
[ERROR] The POM file
[ERROR] /private/tmp/sdk-java/pom.xml
[ERROR] cannot be uploaded to Maven Central due to the following reasons:
[ERROR]  * <url> can not be blank.
[ERROR]  * <licenses> block is required but was left empty.
[ERROR]  * <developers> block is required but was left empty.
[ERROR]  * The <scm> block is required.

Additionally, -sources and -javadoc are needed as well.  I can provide a PR that covers these requirements.

@aalmiray If you have the time to provide a PR, please do so. We want more people aboard 😄

This may be closed now that #9 has been merged 🎉

Is it really done? Has the SDK been published to Maven central? If I understand what the PR does correctly, it can be published now, but it hasn't happened yet, am I right? "There aren’t any releases here"

A Github release is not the same as publication to Maven Central. v1.0.0-draft6 is available from Maven Central. https://search.maven.org/artifact/dev.cdevents.sdk-java/cdevents-sdk-java/v0.1.0-draft6/jar
The current configuration does not create GitHub releases. I've raised #22 to discuss options.

@tomek-pv that's a good question, I did publish what's currently tagged as v0.1.0-draft6 to maven central but we have no GitHub release yet - mainly because I would like the SDK Java team to check everything is in shape for that :)

@aalmiray I saw your reply after I posted mine 😅

Thanks guys, that makes sense. Let's keep this closed and move the discussion to #22


WIP: improving helm setup

Main thing here is to have a way to see if changes to charts are at least valid in the PR.
I see ./test/run-helm-tests.sh, but I am not sure how this is being called. In the docs it says that this is being used by the CI, but  I don't see it. Can we remove it?

@knelasevero https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-sigs/descheduler/descheduler-presubmits-master.yaml#L146-L170

So based on https://github.com/kubernetes-sigs/descheduler/blob/master/charts/descheduler/templates/tests/test-descheduler-pod.yaml#L30 the helm test only checks the descheduler job completed. @damemi I wonder what's the scope of the helm test? To "just" verify the descheduler got "properly" deployed? Does not seem we are testing any functionality here.

@ingvagabund it doesn't test that also... It seems to pass even when some stuff fails.
@damemi I saw that chart releaser was being used here on GitHub actions, and there are quite a bunch of ready to use GitHub actions for helm, so we don't have to reinvent the wheel. I wonder if we can't leave everything helm related on actions, and everything else on prow [?]

@damemi  Makes sense! Thanks for pointing me in the direction of the prow test :)

Ok, I was having a look over other sig sponsored projects that have anything with helm charts, and it seems that people only check lint and sometimes the ct install. Some use gh-actions, some use prow (most just check linting):

ingress nginx on prow, but only linting: https://github.com/kubernetes/test-infra/blob/5ed7f2609f61a8ddfb5ee2ecb51f098e6a895edc/config/jobs/kubernetes/sig-network/ingress-nginx/ingress-nginx-presubmit.yaml#L93

external-dns on gh-actions (same approach that I have added here, and same that we have added for external-secrets): https://github.com/kubernetes-sigs/external-dns/blob/master/.github/workflows/lint-test-chart.yaml

I think it would make sense to remove the one from prow and leave it here. Would require a PR to test-infra, and then I would remote the script from here. So let me know if I should pursue that.

@knelasevero sounds good to me, just wanted to make sure we weren't doing something totally unprecedented. Thanks for offering to handle the work for that

Started by removing the test from prow: https://github.com/kubernetes/test-infra/pull/26630
After that I will continue removing stuff from here, and then I will go forward with improving the helm checks on gh-actions.

Hey @damemi, I will remove wip from this PR then. So we can merge the helm workflow and check its results. (as per your comment on https://github.com/kubernetes/test-infra/pull/26630#issuecomment-1161912089).
Then after that I can followup with removals in k/test-infra and also removals of the scripts here.

/lgtm


[openwrt-18.06] i18n: fix + sync translations

Signed-off-by: Martin Schiller<EMAIL_ADDRESS>

@hnyman Updated this PR, because there were some problems in openwrt-18.06 po files. (see commits)

What can I do to get this fixes merged into 18.06?

Thanks. I applied the three simple fix commits individually.
Regarding i18n-sync, adblock and travelmate require special handling, as their cosmetic changes would disable existing translations. I dir a i18n sync myself for the other apps.


Implement dumps

General info
Closes #35.
This PR implements the dumps route of the MeiliSearch API.
For more details about dumps: https://docs.meilisearch.com/references/dump.html
What does this PR do?
Implement dump creation route
The new class Dump works as a wrapper for MeiliSearchRequestHttp and handles the creation of the dump with the method createDump. This method returns a Dump object which contains:

uid that is the unique identifier of the dump
status which indicates the status of the dump at the moment of the call

The method createDump is finally called by the Client class in a method of its own, that also returns an instance of Dump.
Implement get dump status route
Very similar to the previous point, it uses the new Dump class in coordination with the Client class to make an HTTP GET request and retrieve the current information of the dump. It uses the method getStatusByUid(String uid) in the Dump class and the getDumpStatus(String uid) in the Client class.
An example return value of getDumpStatus
{"uid":"20201218-023314939","status":"done"}

Add tests
To validate the previous 2 points, two new tests were implemented in  the ClientTest class. This tests are testGetDumpStatus and testCreateDump.

testCreateDump creates a dump and validates if it has a status of in_progress
testGetDumpStatus creates a dump and gets its uid. Then it validates if it can retrieve the status using getStatusByUid

Add code samples
In this part I wasn't sure where should I include the code samples. But here they are:
import com.meilisearch.sdk.Client;
import com.meilisearch.sdk.Config;
import com.meilisearch.sdk.Index;
import com.meilisearch.sdk.Dump;

class TestMeiliSearch {
  public static void main(String[] args) throws Exception {

    final String documents = "["
      + "{\"book_id\": 123, \"title\": \"Pride and Prejudice\"},"
      + "{\"book_id\": 456, \"title\": \"Le Petit Prince\"},"
      + "{\"book_id\": 1, \"title\": \"Alice In Wonderland\"},"
      + "{\"book_id\": 1344, \"title\": \"The Hobbit\"},"
      + "{\"book_id\": 4, \"title\": \"Harry Potter and the Half-Blood Prince\"},"
      + "{\"book_id\": 2, \"title\": \"The Hitchhiker\'s Guide to the Galaxy\"}"
      + "]";

    Client client = new Client(new Config("http://localhost:7700", "masterKey"));

    // An index is where the documents are stored.
    Index index = client.index("books");

    // If the index 'books' does not exist, MeiliSearch creates it when you first add the documents.
    index.addDocuments(documents); // => { "updateId": 0 }

    Dump dump = client.createDump();
    String status = dump.getStatus(); // in_progress
    String dumpUid = dump.getUid()); // 20201218-023314939
    String statusAfterCreation = client.getDumpStatus(dumpUid); // {"uid":"20201218-023314939","status":"done"}
  }
}

If you guys have any questions regarding this PR, please let me know. And if you have any feedback is very appreciated 😄!

Hello @luis-valdez!
Thanks again for your involvement! As @eskombro said, the holiday season will start for us soon, so we won't be available for a moment.
Btw, I've just added you to the repository with write access since you are really involved! 😄 Now you don't have to work on your forked repository anymore. More convenient! 😉

We also noticed you don't appear in the contributors of this repository despite your several PRs

I've investigated, and it might be your commits that are not linked to the address email of your account. It means GitHub cannot know your GitHub account luis-valdez is linked to your commits. We think you highly deserve appearing in our contributor list, so if you are ok with it, you might want to set your email to your git config:
$ git config --global user.email<EMAIL_ADDRESS>
😁

We also noticed you don't appear in the contributors of this repository despite your several PRs
I've investigated, and it might be your commits that are not linked to the address email of your account. It means GitHub cannot know your GitHub account luis-valdez is linked to your commits. We think you highly deserve appearing in our contributor list, so if you are ok with it, you might want to set your email to your git config:
$ git config --global user.email<EMAIL_ADDRESS>
😁

Hello @curquiza, first of all, thank you a lot for adding me as a collaborator 😄!
I noticed that same issue too! I believe I already fixed it and when my next PR is accepted I'll appear as one of the collaborators.
Thank you a lot for letting me contribute, and happy holidays 🎉 !

Hey @eskombro! Glad to see you back.
You're right, I was violating the Single Responsibility Principle, and I wasn't noticing.
I implemented the DumpHandler class. And refactor the code to meet your requests.
Thank you a lot for your feedback, and let me know if there's anything else you think can be improved 😄

bors try

Yes I agree, the code is way more understandable now. Great code review!
If you think it'll be okay then I'm good with merging it as it is.

It's safe, this is what will be committed:
https://github.com/meilisearch/meilisearch-java/commit/2ef9d2ad8444c7ac47c71edca6a7a4237251edb3
So no worries @luis-valdez, thanks for this PR!!! 🎉
bors merge

bors merge


Fix the Audio Listener 3D property not being grouped with 2D in Viewport

This is a regression in master; the original issue is not present in 3.x.

Thanks!

I'm pretty sure this was my fault, sorry about that!


Empty values when printing

Hello,
i'm trying to figure out why when increasing the print time from 1 second to 30 seconds i always get empty values.  Any thoughts?
PS: 5 seconds, 10 or 15 seems ok.

This could just be a timing issue when the data has been updated? Always ensure that the checksum has been calculated correctly, and then if that is valid, use that posted result.
I haven't been able to replicate that particular issue in my setup, however I am using hardware serial rather than software serial.


Project Error List

Add the project error list feature. The error list is a panel that displays all the errors in the current project. The list is updated in real time. The current project can be either a configured project with a tsconfig.json file, or a inferred project for a loose file.
Because node is single threaded and analyzing errors in the project level constantly is expensive, we created a dedicated worker server just for the task. To avoid taking up too much memory, the serve only starts if the error list panel is active, and it will be shutdown once the panel is closed.
Demo:

Note in the task manager it can be seen how the worker node server is created and closed.
Note2: this feature is only available for ST3 due to the multi-threading issues in ST 2.

This looks really awesome! However, when I started testing it out, it would cause Sublime 3 to periodically freeze about every 20 seconds on a relatively small project (couple hundred lines of TS). I'm running OSX Yosemite, and my machine is a few years old but it's still pretty fast. I do think it's coming from this branch because I switched back to master and the behavior disappeared.
The weirdest thing is that the errorlist does not even need to be open for this to happen. I caused it simply by checking out the branch and typing in some TypeScript.

I did change the logic for the error requests and quick infos. However it seemed to run fine on my old Mac mini (Yosemite) when I tested it. What do you see in the console output? Could you change the log level to DEBUG and paste the output here? Thanks for testing it btw

Sure!
https://gist.github.com/johnfn/0d8d1bf7e4de78d0e4bc
Here's another one: https://gist.github.com/johnfn/0d8d1bf7e4de78d0e4bc
I guess I should also mention that I'm using Vintageous. I dunno if that could cause the issue. I can try disabling some plugins if you think it might be some sort of plugin conflict.

@johnfn The issue is related to #187, which appears to be a sublime text issue. Do you still have problems using the errorlist with the Vintageous plugin disabled?

How can I trigger TypescriptGoToError command?

By hitting enter on the error list item
From: tien<EMAIL_ADDRESS>Sent: Jul 20, 2015 6:47 PM
To: Microsoft/TypeScript-Sublime-Plugin
Cc: Zhengbo Li
Subject: Re: [TypeScript-Sublime-Plugin] Project Error List (#243)
How can I trigger TypescriptGoToError command?

Reply to this email directly or view it on GitHubhttps://github.com/Microsoft/TypeScript-Sublime-Plugin/pull/243#issuecomment-123126892.

Hitting enter doesn't work for me. Which part of the code is responsible for that? I am thinking it is Default.sublime-keymap but I do not find this file in the pull request. I may be missing something.

:+1:


Feature request

Always i have a bunch of times to insert a record if is not already inserted if a unique column.
Can you guys make a function method to something like this in the model class
$model->where('id != ', $id)->insert($insert_data);
It is verry frustrating that i have to do always a get request to check if the record exists.

I mean insert an record if a record do not already exist in the table by another column that the primary key.

Please open feature requests as a thread in https://forum.codeigniter.com/forum-29.html