Handle partial responses when the server returns an error

XXX in QueryManager#makeRequest.

Still haven't fixed this

Interesting news: Relay doesn't do anything about this. They just ignore the error and put the incorrect data into the store. Perhaps this is because the Facebook backend doesn't return errors like that?

Hmmm, so if the server sends a partial response plus errors, you just receive the partial response?
Do you know how they deal with https://github.com/apollostack/apollo-client/issues/106?

They just overwrite the store with 'null' so you can't actually tell if something is missing due to an error or if it's actually missing. I asked them about this specifically.

Marking this as low priority because Relay doesn't do this, and GraphQL-JS doesn't even have a way to get this information.

I've started playing with apollo-client and run into a problem which I guess it's already discussed here (not sure though - I didn't want to open another issue :P)
I'm making a following query to my graphql server with GraphqiQL:
{
  team {
    name,
    members {
      name
    }
  }
}

As a result I'm getting some data and an Error, because one team member had an incorrect id. It's not ideal, but I consider this as a valid response. Unfortunately when I make the same query with apollo-client I'm getting only a list of ApolloErrors. In my opinion this is an incorrect behaviour.

In my opinion this is an incorrect behaviour.

Relay will do something similar - basically, since errors don't come with a reliable location there is no way to know which part of the response is reliable. This is something we're actively trying to get fixed in GraphQL itself.
But perhaps we could add an option to be a bit looser with error handling.

+1 for a config option. I would like to be able to deal with incorrect data myself while the proper GraphQL solution is being developed.

So here's where that gets handled: https://github.com/apollostack/apollo-client/blob/10cfa7962e58f226573ae6eb63f30c2ce528d7ea/src/QueryManager.ts#L273
What should we do instead?

@stubailo Thanks for the context-- I'll take a look tonight and give you my thoughts tomorrow.

👍  For this to.
Being able to use the errors to decide what to do with the data that is returned will be helpful.

At a high level, what would be ideal for our use case would be an option passed to ApolloClient:
const client = new ApolloClient({
  partialResultsOnError: true
})

When this option is set, and a query contains errors, the client would resolve successfully with what information it did receive and attach an errors field:
{
  data: [{
    team: {
      members: [{
        id: 'b',
        name: 'Foo Bar'
      }, null, null]
  }],
  errors: [ Error(could not find id 'a'), Error(could not find other id 'c') ]
}

If partialResultsOnError is false, the client would act exactly as it does now.
How well does this fit into the existing system?

So here's the long and short of the problem.

Apollo uses a global cache to store all of the data you have ever fetched, which is important if you want your UI to be consistent, or you need to handle mutation results and have them show up properly.
GraphQL.js simply returns null on any field where there is an error, and doesn't have any indication of where in the response the error happened.

So, basically this unfortunate situation can happen:

You fetch query A, the result is cached
You fetch query A again, but this time there's an error that caused a null, the result is cached
Now, you have a null in your cache, even thought you had some good data from (1)

Given that there's no way to tell the difference between a real null result and an error, we decided it's best to just keep the original data and not let the new result "poison" it.
What's a different approach that would be better?
For example, we could just always put the data in the cache and deal with the fact that it might be wrong; we could have a configuration option that would let you look at the error and say whether the result should be used or not; maybe something else?

I don't know how caching is done in apollo, but in the example I've shown I'd like to render as much as I can for my UI. When making a request for a team and team.members, I'd like to show all the information about a team and use data about those people I could get from team.members. With current state when one members fails I cannot use any of the data.
With this being said I think it's a good approach to put all of the data into the cache even if it's invalid or at least make an option to mark queries which might fail (and put them always in a cache).
SideNote Regarding the second point:

GraphQL.js simply returns null on any field where there is an error, and doesn't have any indication of where in the response the error happened.

For this example query
{
  team {
    name,
    members {
      name
    }
  }
}

I'm getting:
...
    {
      "message": "Error: cannot GET http://peopleapi.com/people/testID (404)",
      "locations": [
        {
          "line": 5,
          "column": 6
        }
      ]
    },

Which, as far as I understand, will show where error happened in the query. Of course it doesn't tell everything, because for example it will not tell which member exactly it was, but it might be interesting to use it to invalidate only a part of a query by apollo.

We could take advantage of this PR we added to graphql-js, to know exactly where the error happened: https://github.com/graphql/graphql-js/pull/396
But yeah, I'd be OK to add an option to ignore the errors and just put everything into the cache until reporting the error path is part of the GraphQL spec.
Do we want it to be per-query, or global?

Per-query is probably more user-friendly as it gives the finest level of control. But maybe there could be a global option as well which would provide a default. I'm suggesting this because personally I would like to turn on a global option and not worry about it, but other people might need to cache more aggressively or maintain functionality without a network connection.
Is there currently a pattern for per-query options with a global default?

No - let's add the thing that you need, and if someone comes along and needs per-query control then we'll add it later. I'd rather not add hypothetical features.

Sounds good. One more question: should this behavior apply to mutations as well? We're not using mutations yet so I'm less familiar with that area.

Yes, mutation results are handled pretty much the same way. One thing that's unfortunate is, it would be good to differentiate an error that caused the data to not be saved, from an error in the subsequent refetch. But I don't think GraphQL lets us do that today.

@stubailo do you think it's better to leave a fix in your hands or should one of us create a PR (@nmuth, @zhewison or myself)? It's not super urgent, but it would be definitely nice to have it.

@BartKrol @nmuth @zhewison We love PRs on all our repos, so one of you should definitely create a PR! :tada:

Initially we'll just provide an option to choose between writing or not writing the result into the store when an error happens.

@stubailo @helfer
Awesome that you've included this in the next milestone!
We're locked into v0.4.20 for now and since master is very much diverged from that; I've created a patch for v0.4.20.
The returnErrorsWithResults configuration is currently not covered by the tests in this branch as i'm conflicted on the longevity of v0.4.20.
https://github.com/apollostack/apollo-client/compare/apollostack:v0.4.20...zhewison:errors-with-response
Can you let me know if this is helpful or should be implemented in master? I'm unsure on the timeline for the next milestone.
I can open a PR if you have any comments. Thanks!

Just hit a glitch with this issue too. Apollo reject all GraphQL response because of one error. Where are we with this?
Anyone jumping on it yet?

Error handling is high on our list of priorities, but we decided not to do it for 0.5 yet.

Any news on this? This is pretty important in my opinion :slightly_smiling_face:

@marktani it's not high on our list of priorities, but we're definitely open to a PR. What makes this tricky is having predictable and identical results when hitting the cache vs. requesting from the server. I don't really know what the right solution there is, so it would help to have a couple of real-world use-cases so we can weigh the pros and cons of each option. Maybe you could describe your use-case here for a start! 🙂

{   member { # resolves from DB     firstName     ...     tweet(latest:true) { # resolves from twitter api        ...      }   } }
If an external api fails, it doesnt fail gracefully where i think we all in this use case would want it too

I came up with a workaround by creating a custom network interface: https://gist.github.com/ali/4884425affbe43f9db85726fecf7d033
Since a partial response is a response with both data and errors, my solution was to wrap Apollo's network interface and make it ignore errors. 😛 I know, unspeakable. It'd be nice if I could additionally retry the request (or just the parts of the query that failed) so that I could potentially update the store with the full response behind the scenes.
Here's our use case: Our GraphQL service calls out to another service to resolve the isOnline field on our User type. Sometimes this part of the query will fail, and I'll get a response with all our users' data except for that isOnline field. I'd like to be able to still render these users and display them as offline until I can refetch their online status.
My actual workaround in production is to use a separate container and query just for that isOnline and nest it inside containers that query for the rest of a user's fields.

Maybe you could describe your use-case here for a start!

My use case is any kind of error that happen after/during the query resolving. So it's a valid query as far as the GraphQL type system can tell, but another layer determined it's an error.
In the case of Graphcool, this is mostly permission errors - a node or field was included in the query that the requestee has no permission to access. Here's an example query:
query {
  allDocuments {
    public
    optionalSecret
  }
}

{
  "data": {
    "allDocuments": [
      {
        "public": "Everyone can read this!",
        "optionalSecret": null
      },
      {
        "public": "And this as well",
        "optionalSecret": null
      }
    ]
  },
  "errors": [
    {
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "allDocuments",
        0,
        "optionalSecret"
      ],
      "code": 3008,
      "message": "Insufficient Permissions",
      "requestId": "cizfflsqy5n4q0188qhz66euh"
    },
    {
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "allDocuments",
        1,
        "optionalSecret"
      ],
      "code": 3008,
      "message": "Insufficient Permissions",
      "requestId": "cizfflsqy5n4q0188qhz66euh"
    }
  ]
}

+1 on this.  One easy option might be to support a .finally(response) block on the query promises.

hey, any news regarding this issue?

This would be quite important for a project I'm working on too. Use case (dummy schema):
getCustomers {
  name
  email
  favouriteBook {
    id
    name
  }
}

favouriteBook needs to be fetched with a resolver for each Customer in the list, via http, as it's in a separate micro-service. If one of the resolvers fails, meaning that we don't get a group for that customer, apollo client doesn't return the remaining data, even though it comes in the network response. This means that the entire list fails to display, even though only one of the elements had an error.
Now, maybe we can handle this in the resolver by catching the error and returning empty data, however it would still be helpful to see the errors, as taking this approach would completely hide potential problems.

@helfer @stubailo I'm still learning about this problem (and Apollo), but:
In an imaginary Apollo configuration where partial results and errors are returned, could these be cached, too? I.e., a cached response would indicate errors (and partial data), which would then be overwritten (errors cleared) if a new, successful response comes back from the server?
In react-apollo, errors could maybe even be passed to a component as a prop in this mode?

I have been living in blissful ignorance for the last 6 months thinking this had already been fixed :-)
The GraphQL spec is pretty explicit about supporting partial responses and the errors field containing detailed information.
As the most popular GraphQL client I would expect Apollo to have a strong story around error handling.
@helfer @stubailo - what can Graphcool do to help move this forward?

@sorenbs this is currently blocked on the store refactor which we're working on at the moment. Currently the plan for the new API is to handle errors the same way as we handle data, and write them into the store as well if they have a path (which means you might retrieve cached errors from the store). I'm not yet 100% clear on what we should do with errors that don't have a path, but my intuition is to give people a lot of control around how they want to handle those, and decide on a per-query basis whether something with errors should be written to the store or returned from the store. This will make it very easy to configure Apollo Client in just the way people need, but it comes with the drawback that it will be more complicated to tell what's really going on, which is why choosing sensible defaults will be very important.
What you could help us with is letting us know exactly how you would want your client to behave in different circumstances, and helping us choose sensible defaults so that Apollo Client does what people expect right out of the box (while keeping options open to modify its behavior).
Here are some questions to discuss:

Should errors (with/without path) be written to the store?
Should errors be retrieved from the cache if an earlier query errored on the same path?
What should happen with queries that have errors without path?
How should GraphQL errors be delivered to components? How about non-GraphQL errors?
If we don't cache errors, how should we deal with them during SSR?

There are probably a few more missing here, but

Thanks Jonas - that's awesome news!
I very much agree with allowing developers to configure the behaviour, and agree the sensible defaults are super important.
I'll take some time soon to write up my perspective on this.

Hi !
@helfer  thanks a lot for all the work you do, that's amazing !
Do you have any leads about when the release of the "error handler feature" for apollo-client is due ?
And moreover, we're currently implementing an error handling system following this article.
If we return something like :
{
  errors: [{
    message: 'Request is invalid.',
    path: ['createUser'],
    myCustomErrorData: {
      '': ['Failed to create a new user.'],
      email: ['A user with this email already exists.']
    },
    ...
  }]
}

Do you think that 'myCustomErrorData' will be accessible with the apollo-client's latest release ?
Cheers,

@thifranc you could use response.graphQLErrors[0].myCustomErrorData to access the data.

Can we re-open this? The problem still exists—I just hit it today.
Querying event data means that for some languages e.g. a town might not exist and returns null.
query eventQuery {
  transaction(id: 111111) {
    performance(siteId: 1) {
      venue {
        name
        town
      }
    }
  }
}

We get this response:
{
  "data": {
    "transaction": {
      "performance": {
        "venue": {
          "name": "Kobetamendi",
          "town": null,
        }
      }
    }
  },
  "errors": [
    {
      "message": "Error trying to resolve town.",
      "locations": [
        {
          "line": 9,
          "column": 11
        }
      ]
    }
  ]
}

Apollo doesn't pass any of the partial data it gets right now, which is frustrating.

@helfer Is there any traction on this?

@oliverjamI am facing the exact same issue you mentioned. @stubailo  do you have any updates?

@jbaxleyiii has this been resolved with the new error policies? BTW we might want to add a message to the bot that says you can make it not stale by commenting

@jbaxleyiii please let us know if this is fixed. Its affecting my design decisions.

https://www.apollographql.com/docs/react/basics/queries.html#graphql-config-options-errorPolicy
This has solved all my problems

awesome!!!!!! thank you!!

I'm getting the same unexpected behaviour as @AndrewHenderson with using errorPolicy: all.
The network request contains both data and errors properties, but somehow react-apollo skips errors when merging the result passed to the component props.
However, I am able to catch said errors via middleware.
One (innapropiate) alternative I found working for now is manually requesting the query and processing the callbacks:
this.props.client.query({
        query: getVendor,
	variables: { id },
	errorPolicy: 'all'
}).then(({ data, loading, errors }) => {
	// Props are available here, but are not assigned to the component props
        // when using the graphql decorator
})

Hi all - a lot has changed since this issue was first created. Apollo Client now has much better error handling capabilities. I'll close this issue for now since most of the comments here are outdated, but please open up new issues if you run into further error handling problems with current day versions of apollo-client. Thanks!


Is there support for Oauth?

Sorry I couldnt find information anywhere. Does this implementation support OAuth?

Hi, we have an Open ID Connect provider (https://github.com/spruceid/siwe-oidc). Does that fit what you're looking for?


[BUG]:Property 'notNull` in the timstamp type

What version of drizzle-orm are you using?
0.29.0
What version of drizzle-kit are you using?
0.20.4
Describe the Bug
export const real = pgTable("real", {
	// You can use { mode: "bigint" } if numbers are exceeding js number limitations
	id: bigint("id", { mode: "number" }).primaryKey().notNull(),
	createdAt: timestamp("created_at", { withTimezone: true, mode: 'string' }).default((now() AT TIME ZONE 'Asia/Seoul':: text)).notNull(),
	name: text("name"),
		msg: text("msg"),
});

after drizzle kit pull from the supabase schema I got error message
notNull() does not exist on type 'PGTableWithColumns'
but I found it is ok
createdAt: timestamp("created_at", { withTimezone: true, mode: 'string' }).defaultNow().notNull(),
so I guess it is some syntax problem while constraint of timestamp value
even I never touched, but I don't know how to touched
name , and msg below the createdAt also affected and throw error
Left side of comma operator is unsued and has no side effect
Expected behavior
after drizzle-kit push every thing is ok
Environment & setup
i got data from the supabase

I realize this table is real time checked table
does it matter?
should I seperate other schema when I table set as realtime ?


mapToolbar won't disable

I'm submitting a ...  (check one with "x")
[ X ] question
[ ] any problem or bug report
[ ] feature request
The plugin version:  (check one with "x")
[ ] 1.4.x
[ X ] 2.0.0-beta3
If you choose 'problem or bug report', please select OS:  (check one with "x")
[ X ] Android
[ ] iOS
cordova information:  (run $> cordova plugin list)

Ionic info

cli packages: (C:\Users\HP\Cheeper-1-0-3\node_modules)
@ionic/cli-utils  : 1.9.2
ionic (Ionic CLI) : 3.9.2
global packages:
Cordova CLI : 6.5.0
local packages:
@ionic/app-scripts : 2.1.3
Cordova Platforms  : android 6.2.3
Ionic Framework    : ionic-angular 3.6.0
System:
Node : v7.10.0
npm  : 4.6.1
OS   : Windows 7

cordova plugin list

cordova-plugin-browsertab 0.2.0 "cordova-plugin-browsertab"
cordova-plugin-buildinfo 1.1.0 "BuildInfo"
cordova-plugin-calendar 4.6.0 "Calendar"
cordova-plugin-compat 1.0.0 "Compat"
cordova-plugin-console 1.0.5 "Console"
cordova-plugin-customurlscheme 4.3.0 "Custom URL scheme"
cordova-plugin-device 1.1.4 "Device"
cordova-plugin-facebook4 1.9.1 "Facebook Connect"
cordova-plugin-geolocation 2.4.3 "Geolocation"
cordova-plugin-googlemaps 2.0.0-beta3-20170820-2025 "cordova-plugin-googlemaps"
cordova-plugin-headercolor 1.0 "HeaderColor"
cordova-plugin-inappbrowser 1.7.1 "InAppBrowser"
cordova-plugin-nativestorage 2.2.2 "NativeStorage"
cordova-plugin-network-information 1.3.3 "Network Information"
cordova-plugin-splashscreen 4.0.3 "Splashscreen"
cordova-plugin-statusbar 2.2.2 "StatusBar"
cordova-plugin-whitelist 1.3.1 "Whitelist"
cordova-plugin-x-socialsharing 5.1.8 "SocialSharing"
cordova-universal-links-plugin 1.2.1 "Universal Links Plugin"
es6-promise-plugin 4.1.0 "Promise"
ionic-plugin-keyboard 2.2.1 "Keyboard"
Current behavior:
Maptoolbar is still showing even after setting in the controls the option mapToolbar: false
Expected behavior:
maptoolbar stop showing when boolean false is set.
Steps to reproduce:

Screen capture or video record:

Related code, data or error log (please format your code or data):
Here is the code section that I wrote:
https://gist.github.com/thezakman/862a9e911857a1953d750bb000f23342

If your problem is solved, please consider small amount donation to this project.
Appreciate for your kindness.
https://github.com/mapsplugin/cordova-plugin-googlemaps-doc/blob/master/README.md#buy-me-a-beer

The bug was fixed in the @ionic-native/core and @ionic-native/google-maps ver4.2.0
Please reinstall these two packages.
https://www.npmjs.com/package/@ionic-native/core
https://www.npmjs.com/package/@ionic-native/google-maps

Confirmed.


Hint message on stop is reversed

Error message should show reverse, as user: sudo.., and as root: not sudo

Thanks for the followup fix :+1:


check to which degree phoible describes existing datasets

With the benchmark database of phonetic alignments and the benchmark data for cognate detection there are two large datasets which provide phonetically segmented data. The question, also with respect to the idea that we might link individual sounds to phoible, is now: to which degree covers phoible the sounds in those and maybe also other datasets?
By carrying out this small analysis, we would have a better estimate on how difficult it is to use things like phoible for reference in our future endeavours (or whether we need to come up with an alternative system of tracking sounds ourself, that, eventually, may built upon phoible).
One further important point on mapping things to phoible is, that we should not underestimate the problems of IPA-variation. IPA has, for example, versions for /ts/ both as single character, as two characters, and as two characters with a combining character. There are also two versions of g, different ways of describing tone, and all other kinds of problems. Now, in order to use phoible as a reference, we need to come up with a mapping of all these variants to the respective phoible symbols, and preferably also with a mapping of non-standard IPA variants, like /th/ for aspirated t, which we will frequently encounter in the lexical data. This could turn out to be quite tedious, but also useful. Anyway, the starting point is to check to which degree we find agreement between the above-mentioned databases and phoible, but potentially also Paul's sound comparison databases.

Good idea. I think what makes PHOIBLE so useful is exactly the fact that it tries to remove the ambiguities still inherent in IPA. While I do not have much hope of fully automatic conversion of messy data like IDS to proper (PHOIBLE-)IPA, I at least think, PHOIBLE can provide an important piece for quality assessment - in some sense its a benchmark database as well.

Update on this matter: I just run a test (code is at glottobank/phonobank-data/tests/phoible-integration) along with all datasets (alignmetns and wordlists).
The results are here. In brief: 578 elements do not occur in Phoible, while 360 occur. Generally the dataset is quite huge with a total of 74562 words.
Inspecting problematic elements you can find in the file mentioned above, we see that most of them are vowels (almost all diphtongs). Tones are encoded differently, so here one might adjust (though I hate the tone marks used in phoible). The consonants, there are 128, are often due to the variants we discussed, maybe all of them, but this needs a closer inspection.
So, if we put the vowels at the side or treat diphtongs as consisting of single vowels, we might actually come to some raw phobile coverage. One might even use the lingpy-sound-class alphabet to create some mapping of data like the one I tested here to "phoible". In the end, all can be treated as some specific sound class.

One more thing: In LingPy, we have a default character that shows that a given sound cannot be mapped to a sound-class alphabet (when there are errors). The same could, of course, be done with a phoible mapping...

An update: many of the cases which do not map are errors. But not all. Phoible does not, for example, know the diphtong əʊ which is often used in transcriptions for things like English "swallow" or the like. Now, how do we deal with these cases? And there are more!
SEGMENT	FREQUENCY	CLASS
əʊ	10	V
auː	7	V
eiː	6	V
ouː	6	V
ɛˀ	5	V
øyː	3	V
yˀ	2	V
ɔˀ	2	V
ɒˀ	2	V
øːʌ	2	V
æˀ	1	V
øˀ	1	V
ɶ	1	V
aiː	1	V
ɶˀ	1	V
ʏː	1	V
ɑˀ	1	V
œˀ	1	V
ðˀ	4	C
ʁˀ	4	C
gː	2	C
b̥	2	C
d̥	1	C

Note that not all of these are unmappable, but some are definitely.
My suggestion would be to follow the lingpy tactics:

try to identify segment (include down-mappings, like all variants of ts, and the like)
if you still can't identify a segment, try the first letter of the segment (token[0]).
if you still can't identify this, mark it as unmappable.

We can further adopt the strategy for diphtongs:

if the diphtong can be segmented into values occuring both in Phoible, split it.

At some point, we might want to involve the phoneticians among us. It seems still strange to me, that certain sounds do not occur in Phoible...

@LinguList I guess, I am more interested in figuring out whether PHOIBLE can be used for quality assessment on a per wordlist of per language basis. I.e. if all segments used in word forms of a wordlist are found in the PHOIBLE segment inventory for the respective language, I could be quite confident, that the forms are transcribed in IPA and thus comparable to other datasets. E.g. some of the IDS wordlists contain unicode glyphs from cyrillic code blocks which look like IPA glyphs. Such problems could be detected when cross-checking with PHOIBLE, I guess, unless the rate of false positives is too high, because the PHOIBLE inventory doesn't really describe the reality of these wordlists.

Okay, but in order to proceed, you will anyway need a mapping of those IPA-internal ambiguities to the phoible version, not? And since phoible itself doesn't seem to transcribe (yet) all possibilities, we need strategies to check, for example, for certain diphtongs. Also, accent marks need to be stripped off, as well as other marks which are relevent for a word transcription but not for an inventory transcription.

Yes, such a mapping or normalization would be great to have. I don't think PHOIBLE aims to catalog all possibilities, but only whatever has actually been put into phoneme inventories by linguists. So I would find it more tractable to work on a wordlist-by-wordlist basis and aggregate common pitfalls into such a normalization script, rather than trying to code up all of the PHOIBLE conventions in one go - just to find out, the data we deal with isn't any IPA et all, but could be made so with a couple of hacks.

Yes, I agree. I already collected a few of them common pitfalls in the past.
I don't know, whether the way I program it is useful, but I have one mapper that maps IPA to IPA.phoible, like this one:
mapper = {
        'p͡f' : 'pf',
        'ʧ' : 'tʃ',
        'g' : 'ɡ',
        'ḷ' : 'l̩',
        'ṇ' : 'n̩',
        'ʦ' : 'ts',
        'ʤ' : 'dʒ',
        'eã' : ['e', 'ã'],
        'eɑ̃' : ['e', 'ɑ̃'],
        'eːaː' : ['eː','aː'],
        'ya' : ['y','a'],
        'ɶː' : 'œː',
        'ɪə' : ['ɪ','ə'],
        'ʊə' : ['ʊ','ə'],
        'gː' : 'ɡː',
        'ɶ' : 'œ',
        'b̥' : 'p',
        'd̥' : 'd'
        }

And I also have one "cleaner", which cleans up the code by general replacement patterns which one can just apply to any string, since they are n to n:
# tuple[0] == source, tuple[1] == target
cleaner = [
        (':', 'ː'),
        ('g','ɡ')
        ]

I've started testing this on my wordlists with segmentation, and I can reach almost full coverage, and the process of adjusting is actually not too tedious. It also helps to clean one's own data.
Here's the current status, btw: glottobank/phonobank-data/tests/phoible-integration/
There are also all the segmented wordlists I mentioned before.

@LinguList Yes, I would hope that this approach works at least 90% of the time.

I'll report on this when I prepare the data for lexibank. I then suppose I add an additional layer of segmentation:

orthography
ipa (as received, without segmentation)
tokens (lingpy-tokens, manually adjusted, which is needed at times)
phoible

Having these three stages seems important to trace where the data came from in the end. Would you agree?

Yes, that's already way ahead of most of the data we will have to integrate, but should define the level of accuracy we want to get at.

Okay, I started working on a function that takes an "ipa" string in some raw form without nasty brackets as input and converts it to phoible (see phonobank-data/tests/phoible-integration/utils.py). This function normalizes already some great deal. I adopted the following conventions (to be discussed, probably, in more detail:

when there are unrecognized diphtongs, check for their constituents, mark this by adding a dot-character between the vowels.

Example:
>>> tokens2phoible('n æ r əʊ')
['n', 'æ', 'r', 'ə.ʊ']

add a question mark before any segment which is not mappable to phoible, example:

>>> tokens2phoible('blu:twurSt')
['b', 'l', 'uː', 't', 'w', 'u', 'r', '?S', 't']

Do this also for the segments of a diphtong, but then only for the vowel in the diphtong set:

>>> tokens2phoible("'b l u: t w uA r s t'")
['b', 'l', 'uː', 't', 'w', 'u.?A', 'r', 's', 't']

There are more small modifications which are included, like representing geminates with a length marker rather than double markers, ignoring accents, etc. The function is a bit complicated, but it should provide some help, and when adding more and more data, we may hopefully increase the accuracy by adding more mappings, etc.

An update: The function works fine so far, but there will be definite problems with phoibles coverage: when testing for germanic and indo-euroepan data, it seems to work well, but for SEA data, it shows a big gap in phoible: first, the actual values are largely erroneous (even Manarin Chinese is assigned wrong tones!), secondly, there are many missing sounds, like, for example aspirated fricatives, and the like. So at some point, we will need to contact Steven and give him the data to be appended to phoible, since there are quite a few sounds missing. Steven may actually be happy about this. But how should we proceed in the mean-time? Should I mark those cases where there is an ambiguous gap in phoible?
BTW: this also answer the question of mapping data to one language explicitly in phoible: we can't do this, since the transcriptions systems vary hugely, and phoible often has some in my opinion not very reliable source (at least for the languages I have worked on so far).

Well, the only way to get data into PHOIBLE is by publishing a phoneme inventory for a language, I guess. AFAIK PHOIBLE doesn't aim at being a catalog of the world's sounds (at least currently). So I would suggest to compile a blacklist of languages for which mapping to PHOIBLE doesn't make sense. Maybe this list could be of interest for Steve, because it may overlap with languages not yet in PHOIBLE, and help prioritise aqcuisition of new inventories.
If we can only map to the set of all segments in PHOIBLE and not to exactly one inventory, this may still be worthwhile in terms of IPA normalization, but it would lose quite a bit of its appeal. (Although, I think, that was to be expected, considering the ideosyncratic transcription systems.)

Well, in that case, I suppose we take phoible as starting point and reference it wherever possible, and start making our catalogue of sounds in the world ourselves. If glottobank really aims at making a difference, and we plan to assemble high-quality data in the future, then we should do this anyway.
Quite a few languages not in phoible can be added from data I have on SEA languages. Here, transcriptions are usually from sources which phoible did not yet find time to digitize, I guess. When preparing the data, I'd suggest to follow phoible's normalization as good as possible, but to eventually mark new sounds to be given to Steven along with the language's phoneme inventories at some point. I thus make up an additional list now with sounds unambiguously missing in phoible, given a certain language. In the utils.py conversion, I'll mark sounds currently not in phoible with '⁽⁺⁾' after the segment (should be clear that this has no phonetic value, and in automatic analyses, it can easily be ignored). In this way, one can directly see for each wordlist, to which degree it is normalized regarding it's ipa, and one can see which of the phoneme inventory (which we may display additionally in lexibank, along with links to phoible), is not covered in phoible.
Does that sound like a useful plan for ipa-normalization? I staretd testing on my data, and most of the time, the ambiguous elements shrink down to a few, and the normalization is also quite useful. I even think of including this at some stage into lingpy. So far, I thought IPA normalization was too tedious, but maybe it's time to try and tackle it, albeit in a pragmatic way...

Sounds workable. Should we move this issue to phonobank, then?

Yes, very good idea! This is definitely then to be handled as one of
PhonoBank's responsibilities.

Okay, I don't know how to move issues on github, and there seems to be no real way to do it unless using some external apps. So I moved this issue to:

https://github.com/glottobank/phonobank-data/issues/2

And I'm closing this one for the meantime.


The type 'KeyValueList' is not defined

Fable.Import.Pixi.fs isn't compatible with the latest Fable anymore.
We need to replace the KeyValueList attribute with a different approach I suppose.

Thanks @realvictorprm.
This is on my todo with bindings upgrade to v4.x


Be consistent in network referencing

We need to be consistent with the network strategy (probably name or integer)

@scottrepreneur suggested

Currently the URLs for invoices is https://app.smartinvoice.xyz/invoice/4268/0x7d535b498687e0eb8f3f7bfb65729ce36da5ae6a
but 4268 here is very misleading and confusing.
We should change the URLs to support all of the following for the example of holesky:

[ ] 0x4268
[ ] 17000
[ ] holesky

Here holesky should be the primary display URL.


Search against a tsvector column

PostgreSQL has a built-in tsvector column type that can be used to store pre-calculated stems of your searchable text.
Right now pg_search always casts the columns you search against into text and then converts them into tsvector on the fly. We should detect if a column is a tsvector and skip that step if so.

#20 adds support for tsvector columns


Typo in description ('pasword' and not 'password')

Enable rcon on server
Remember to enable rcon by adding following lines to server.properties file.
enable-rcon=true
rcon.port=25575
rcon.password=your_rcon_pasword

Good catch!


Use VSSDK Pattern Matcher

Starting with 15.6, the VS editor is going to have the Pattern Matcher available as an API.  MyGet feed here.
This will allow us to remove our internal copy of Roslyn's version from a while ago, and will allow us to remove the dependency on FSharp.LanguageService.Base that FSharp.Editor has.

What does this thing do exactly?
Am 14.12.2017 05:15 schrieb "Phillip Carter"<EMAIL_ADDRESS>
Starting with 15.6, the VS editor is going to have the Pattern Matcher
https://github.com/dotnet/roslyn/blob/master/src/Workspaces/Core/Portable/PatternMatching/PatternMatcher.cs
available as an API. MyGet feed here
https://vside.myget.org/gallery/vssdk.
This will allow us to remove our internal copy
https://github.com/Microsoft/visualfsharp/tree/master/vsintegration/src/FSharp.LanguageService.Base/PatternMatcher
of Roslyn's version from a while ago, and will allow us to remove the
dependency on FSharp.LanguageService.Base that FSharp.Editor has.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/4116, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AADgNAcyGYlXcHM4Uw-6BEyinvx3DZ9Jks5tAKDtgaJpZM4RBhgj
.

@forki it's used in Go to All feature to search symbols. I doubt anybody uses it though.

Also @forki earlier this year, @vasily-kirichenko ported it over (and some of its source-based dependencies) from Roslyn, because the Roslyn version was inaccessible with no plans to open it up. Since then, the editor team has forked the codebase, put it into the editor layer, and are exposing it for consumers starting with 15.6. Since they'll be maintaining this for all users of the assembly it'll be in, we should use that one moving forward.

Done in #14746.


Assert same size of uint64_t and double for bitcast

Scope & Purpose
Just two slight nitpicks I noticed while viewing a diff too late in #19641.

One could also use std::bit_cast.


Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[x] iOS
[ ] Android
[ ] UWP
[ ] .NET Standard

Version of Library
<IP_ADDRESS>4
Version of OS(s) listed above with issue
iOS 14.0
Steps to Reproduce

Call DatePromptAsync or DatePromptAsync TimePromptAsync in your code.

Expected Behavior
A date or time picker should appear.
Actual Behavior
A black box appears covering most of the screen with a small input box.

Any updates on this?

@salgiza  I was be able to fix it by change adding datePicker.PreferredDatePickerStyle = UIDatePickerStyle.Wheels;  for datePicker in the AIDatePickerController. Seems AIDatePickerController are not fully support iOS 14.

this is proberly connected to https://github.com/xamarin/Xamarin.Forms/issues/12258

@salgiza I was be able to fix it by change adding datePicker.PreferredDatePickerStyle = UIDatePickerStyle.Wheels;  for datePicker in the AIDatePickerController. Seems AIDatePickerController are not fully support iOS 14.

may i ask how you changed that?
did you fork this repo and make your own?

@syle20091 how did you manage that?

@rr-autoit Hi, I did it in a very ugly way, because PreferredDatePickerStyle is new in iOS 14, so there is no way AIDatePickerController would expose any API for us to modify this property back to "wheel". So I created my own "AIDatePickerController" and add PreferredDatePickerStyle into the constructor during the initialisation of DatePicker, And pass my modified "AIDatePickerController" to DatePrompt to make it like before.

haha thanks mate, thought it was something like that.

no worries
On Thu, 1 Oct 2020 at 9:51 pm, rr<EMAIL_ADDRESS>wrote:

haha thanks mate, thought it was something like that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aritchie/userdialogs/issues/750#issuecomment-702081407,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJJRFN7LBXGZ2SCCUFVR2VDSIRUMBANCNFSM4RYDGNJA
.

Fixed by PR


Created a UnixConnection to represent UDS connections which has the ability to retrieve the local/remote PID

Connections through a Unix Domain Socket will now be represented by a UnixConnection (which extends a regular Connection). This UnixConnection contains the custom logic for parsing parsing the address and has the new ability to retrieve the local and remote PID.
From the server side a client has no "remote address". The remote PID can for example be used to distinguish multiple clients.
See #150

What's the status on this? Was BC break label added as precaution, or is compatibility truly broken? If the issue is no longer setting the 'unix' public property to true, there's no reason that can't still be done in this PR. Let me know if there's anything I can do to help get this feature merged.

Please let me know if there is something I can do to help with this PR :)


operators argocd-operator (0.3.0)

Signed-off-by: ishitasequeira<EMAIL_ADDRESS>Thanks submitting your Operator. Please check below list before you create your Pull Request.
Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

/merge possible

/merge possible

/merge possible

/merge possible

/approve

@J0zi @mvalarh
I approved the PR and was expecting the CI bot to set authorized_changes label.
I came across this. Does this mean either of you have to approve this PR ?
Pipeline will set authorized_changes label only if last github reviewer is in reviewer list (defined in ci.yaml) and review state is APPROVED

https://redhat-openshift-ecosystem.github.io/community-operators-prod/self-merge-updates/#how-can-i-approve-a-pr-against-my-operator

/merge possible

@J0zi @mvalarh I approved the PR and was expecting the CI bot to set authorized_changes label.
I came across the below statement in the docs. Does this mean either of you have to approve this PR ?
Pipeline will set authorized_changes label only if last github reviewer is in reviewer list (defined in ci.yaml) and review state is APPROVED

https://redhat-openshift-ecosystem.github.io/community-operators-prod/self-merge-updates/#how-can-i-approve-a-pr-against-my-operator

There are several options one can get authorized_changes label if author is not in reviewer list. Please see Author is not in reviewer list. In your case you could approve and then /hold and '\unhold'.

@J0zi @mvalarh I approved the PR and was expecting the CI bot to set authorized_changes label.
I came across the below statement in the docs. Does this mean either of you have to approve this PR ?
Pipeline will set authorized_changes label only if last github reviewer is in reviewer list (defined in ci.yaml) and review state is APPROVED

https://redhat-openshift-ecosystem.github.io/community-operators-prod/self-merge-updates/#how-can-i-approve-a-pr-against-my-operator

There are several options one can get authorized_changes label if author is not in reviewer list. Please see Author is not in reviewer list. In your case you could approve and then /hold and /unhold.

@mvalarh ah I over looked into the docs. I thought I just need to approve, missed the /hold and unhold part. Thanks :)