chore: clean-up ids dispatcher module

What this PR changes/adds
Cleans up the ids-api-multipart-dispatcher-v1 module. Revises package structure, removes inheritance for MultipartResponse and updates Javadoc.
Why it does that
Clean-up of the module was required.
Linked Issue(s)
Closes #1600
Checklist

[ ] added appropriate tests?
[ ] performed checkstyle check locally?
[ ] added/updated copyright headers?
[ ] documented public classes/methods?
[ ] added/updated relevant documentation?
[ ] added relevant details to the changelog? (skip with label no-changelog)
[x] formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

Codecov Report

Merging #1607 (f924eef) into main (21184bf) will decrease coverage by 7.50%.
The diff coverage is 40.00%.

@@             Coverage Diff              @@
##               main    #1607      +/-   ##
============================================
- Coverage     67.80%   60.29%   -7.51%
- Complexity        0     3074    +3074
============================================
  Files           762      770       +8
  Lines         16456    16537      +81
  Branches       1050     1047       -3
============================================
- Hits          11158     9971    -1187
- Misses         4817     6143    +1326
+ Partials        481      423      -58

Impacted Files
Coverage Δ

...atcher/IdsMultipartDispatcherServiceExtension.java
0.00% <0.00%> (-68.75%)
:arrow_down:

...ispatcher/IdsMultipartRemoteMessageDispatcher.java
0.00% <ø> (-50.00%)
:arrow_down:

...ultipart/dispatcher/sender/IdsMultipartSender.java
20.75% <ø> (-59.44%)
:arrow_down:

...patcher/sender/MultipartArtifactRequestSender.java
58.33% <0.00%> (-20.10%)
:arrow_down:

...nder/MultipartCatalogDescriptionRequestSender.java
0.00% <ø> (-6.39%)
:arrow_down:

...tcher/sender/MultipartContractAgreementSender.java
0.00% <0.00%> (-81.82%)
:arrow_down:

...ispatcher/sender/MultipartContractOfferSender.java
0.00% <0.00%> (-89.66%)
:arrow_down:

...tcher/sender/MultipartContractRejectionSender.java
0.00% <0.00%> (-90.91%)
:arrow_down:

...cher/sender/MultipartDescriptionRequestSender.java
0.00% <0.00%> (-68.58%)
:arrow_down:

...ds/api/multipart/dispatcher/util/ResponseUtil.java
66.66% <66.66%> (ø)

... and 63 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 21184bf...f924eef. Read the comment docs.

I think IdsMultipartSender should be refactored in a way to avoid this design based on abstraction since it's hard to read and hard to change. Probably it would require a lot of work but it would definitely bring added value. Not for this PR, just to see if it's a shared thought.

We could do it within this PR as we wanted to refactor and not create new TODOs ^^ I will take another look at the branch

I think IdsMultipartSender should be refactored in a way to avoid this design based on abstraction since it's hard to read and hard to change. Probably it would require a lot of work but it would definitely bring added value. Not for this PR, just to see if it's a shared thought.

Do you want to get in some ideas? Or was it just an initial thought?

I think IdsMultipartSender should be refactored in a way to avoid this design based on abstraction since it's hard to read and hard to change. Probably it would require a lot of work but it would definitely bring added value. Not for this PR, just to see if it's a shared thought.

Do you want to get in some ideas? Or was it just an initial thought? My first idea was to let the MessagSenderss directly implement the IdsMessageSender and to encapsulate its current functionalities into util methods or similar.

My idea would be quite different...
currently the behaviors that are described by abstract methods in the IdsMessageSender are:

retrieveRemoteConnectorAddress
buildMessageHeader
buildMessagePayload
getResponseContent

The first one is straightforward, and I think a RemoteMessage should know about the destination, so it will be enough to add a getRemoteConnectorAddress method on the RemoteMessage interface.
For the three others, I would start the refactor extracting an interface called like MultipartSenderDelegate (or something better :D ) with these three methods, and I would make all the Senders implement it.
At this point a delegate could be injected into the IdsMultipartSender class, that would stop being an abstract class.

I think IdsMultipartSender should be refactored in a way to avoid this design based on abstraction since it's hard to read and hard to change. Probably it would require a lot of work but it would definitely bring added value. Not for this PR, just to see if it's a shared thought.

Do you want to get in some ideas? Or was it just an initial thought? My first idea was to let the MessagSenderss directly implement the IdsMessageSender and to encapsulate its current functionalities into util methods or similar.

My idea would be quite different... currently the behaviors that are described by abstract methods in the IdsMessageSender are:

retrieveRemoteConnectorAddress
buildMessageHeader
buildMessagePayload
getResponseContent

The first one is straightforward, and I think a RemoteMessage should know about the destination, so it will be enough to add a getRemoteConnectorAddress method on the RemoteMessage interface.
For the three others, I would start the refactor extracting an interface called like MultipartSenderDelegate (or something better :D ) with these three methods, and I would make all the Senders implement it. At this point a delegate could be injected into the IdsMultipartSender class, that would stop being an abstract class.

I started working on this, I will create a new PR. This one gets too messy, you were right :D

@ndr-brt Can this PR be merged? Parts of your comments are addressed here, some will be in #1695 and a new PR for #1697.


Fix #32: Error when reading token

This should fix the issue. I have changed the npm version to 0.7.1-alpha.

@himynameisdave could you CR this and then publish it up to npm as version 0.7.1-alpha?

Closes #32

Cheers @himynameisdave - don't forget to npm publish to push out the latest version :stuck_out_tongue_closed_eyes:

haha already have :+1:


remove deprecated files

This looks great! Can you update the changelog as well before we merge this.

Please update your snapshots before I merge this.


Editors on homepage with 2.5 way flow

Two way editors on the homepage
TODO:

Sync on various ideas with the team, particularly around what to edit within the page and how
Action decisions from sync
Fix the dark mode breakages

Closing awaiting further syncs and new editor


Add a cookie fallback in getAuthHeader

The getAuthHeader method currently implements a fallback to request.input('token') if an authorization header is not set. I just add a second fallback to read the jwt from a cookie if neither an authorization header nor a token body are set.
This commit permit to store the jwt in a http-only cookie in order to avoid exposing jwt to js and thereby reduce xss attacks possibilities.

Coverage increased (+0.01%) to 98.485% when pulling d4bd10a0bad4cb06f9dd3f3eb61de1707ea0ccdd on nmrgt:develop into 5364f404868301088f35bb818d98751cbdb5d832 on adonisjs:develop.

So in the related issue I shared that this is not something to be added to the core. Lemme share my concern around it and also share the work around.
Why not cookies?
When adonis-auth JWT will start reading cookies, people will feel free to share their JWT tokens inside the cookie, thinking it is supported by the core and should be safe.
So what everyone will do is
response.cookie('jwt-token', userToken)

Problem with cookies
The problem with cookies are they are open for all sort of attacks, since browser sends them along with every HTTP request.
So let's say a hacker drops in some code in your app, now everytime they make an HTTP request to your server using Javascript ( in short ajax ) the cookies are sent along, which will also send the JWT token with it.
Workaround
Since you think it is a required for certain style of applications, it is better to be explicit, why and where it is done.
What I suggest is creating a middleware, which runs before the auth middleware, reads the cookie and set the header.

Closing since no response from the issue reporter


[Feature] LoRA support

I know everyone wants it, its on the todo haha

I tried implementing it on a trial basis. I would be happy if you could check it
https://github.com/OpenMOSE/RWKV-infctx-trainer-LoRA


Missing Official Figma Components File in your provided segment account

Dear segment/evergreen team, I saw that there is no official figma file in your figma’s @segment account. Could you please provide an (and at least any) official up-to-date component library taht matches the official dev docs (same colors in colors palette / same component property names / etc.)?
Third-party community files are inconsistent
The other evergreen v6 community libraries (from Emmanuel Badmus and Sarah Li) are way to incosistent to your official react development component documentation. This makes working with evergreen very hard.
If I can be of any help, please let me know.

Hey @Coderwelsch, we've republished the Evergreen v6 documentation as it existed prior on the Twilio Figma: https://www.figma.com/community/file/974362403539471944. I'll get a PR out to update the link on our doc site.


Improve error message for epoch mismatch in (un)delegation

Is your feature request related to a problem? Please describe.
(un)delegation transactions have to be prepared with respect to a specific epoch.  This means that there's a narrow window close to the epoch boundary where a client could start preparing the tx with respect to the current parameters, and then have those parameters change before the tx can be submitted.  This results in errors like
could not broadcast transaction: Error submitting transaction: code 1, log: delegation was prepared for epoch 160 but the next epoch is 159

and users are confused because nothing indicates they could retry.
Describe the solution you'd like
Change the error message to add ; try re-building and re-submitting the transaction at the end.

This error message can appear (and has appeared) if one runs an old version of pcli against a newer testnet. However, it also appears if one submits a tx exactly on the epoch boundary, in which case the suggested error message would be very helpful.

Relatedly, we want to adjust the interface for epoch boundaries: @zbuc will file (or cross-link) a follow-up issue to track.


[Feature Request] Direct Python Interface for mlx_vlm.generate

Currently, the mlx_vlm.generate function can only be called from the command line using python -m mlx_vlm.generate. I would like to request a direct Python interface for this function, allowing me to call it from my Python code without having to use the command line.
The desired API would be similar to the following:
from mlx_vlm import generate # Maybe add a load function just as in mlx_lm.generate?

image = "http://images.cocodataset.org/val2017/000000039769.jpg"
caption = generate(model='qnguyen3/nanoLLaVA',
                image=image,
                # processor = Automatically determined by the model choice
                # image_processor = Automatically determined by the model choice
                prompt="Describe this image.",
                temp=0.0,
                max_tokens=100,
                verbose=False,
                formatter=None,
                repetition_penalty=None,
                repetition_context_size=None,
                top_p=1
                )

This would allow me to easily integrate the mlx_vlm.generate function into my Python code without calling a subprocess, and use it to generate captions for images programmatically.

from mlx_vlm import generate
from transformers import (
    AutoProcessor,
    PreTrainedTokenizer,
)
model = 'qnguyen3/nanoLLaVA'
caption = vlm_generate(model=model,
        image=image_path,
        processor=PreTrainedTokenizer,
        image_processor=AutoProcessor,
        prompt="Describe this image.",
        temp=0.0,
        max_tokens=100,
        verbose=True,
        formatter=None,
        repetition_penalty=None,
        repetition_context_size=None,
        top_p=1
)

gives
File "/Users/air/Repositories/test-repo/src/main.py", line 19, in <module>
  main()
File "/Users/air/Repositories/test-repo/src/main.py", line 13, in main
  all_data = process_data(folders, args)
File "/Users/air/Repositories/test-repo/src/data_processing_and_inference.py", line 11, in process_data
  file_processor(folders, args)
File "/Users/air/Repositories/test-repo/src/prepare_data.py", line 205, in file_processor
  concatenate_files(folders, args.word_limit, file_queue, args.images, args)
File "/Users/air/Repositories/test-repo/src/prepare_data.py", line 178, in concatenate_files
  file_text = process_file(file_path, file_type, images, args)
File "/Users/air/Repositories/test-repo/src/prepare_data.py", line 157, in process_file
  return read_pdf_file(file_path, args, images=images)
File "/Users/air/Repositories/test-repo/src/prepare_data.py", line 100, in read_pdf_file
  caption = caption_image_file(image_index, args)
File "/Users/air/Repositories/test-repo/src/prepare_data.py", line 36, in caption_image_file
  caption = vlm_generate(model=model,
File "/opt/homebrew/lib/python3.10/site-packages/mlx_vlm/utils.py", line 691, in generate
  prompt_tokens = mx.array(processor.encode(prompt))
TypeError: PreTrainedTokenizerBase.encode() missing 1 required positional argument: 'text'

This is currently possible, and I will add more documentation examples.
Here how you do it:
model_path = "mlx-community/nanoLLaVA"
model_path = get_model_path(model_path)
model, processor = load(model_path)
config = load_config(model_path)
image_processor = load_image_processor(config)

prompt = processor.apply_chat_template(
    [{"role": "user", "content": f"<image>\nWhat's so funny about this image?"}],
    tokenize=False,
    add_generation_prompt=True,
)

image_path =  "./assets/image.png",
output = generate(model, processor, image_path prompt, image_processor, verbose=False)

Let me know if it works for you :)

It works for me, however it's still quit some overhead to import 5 functions from two different libraries.
Do you happen to have any plans to integrate a more high-level solution where only model, processor = load ... and  generate  = ... are only needed?
Additionaly, adding trust_remote_code for this automatically would be a plus:
The repository for /Users/air/.cache/huggingface/hub/models--mlx-community--nanoLLaVA/snapshots/hash contains custom code which must be executed to correctly load the model. You can inspect the repository content at https://hf.co//Users/air/.cache/huggingface/hub/models--mlx-community--nanoLLaVA/snapshots/hash. You can avoid this prompt in future by passing the argument trust_remote_code=True.
I didn't have this pop-up when generating with the bash line.

It works for me, however it's still quit some overhead to import 5 functions from two different libraries.
Please, show me an example,

Do you happen to have any plans to integrate a more high-level solution where only model, processor = load ... and generate = ... are only needed?

Yes, I do.
Nanollava style models use image_processor alongside processor whilst Llava doesn't. So I want to make it explicit.
Perhaps this would be better:
from mlx_vlm import load, generate

model_path = "mlx-community/nanoLLaVA"
model, processor = load(model_path)
image_processor = load_image_processor(model_path) # None for Llava

prompt = processor.apply_chat_template(
    [{"role": "user", "content": f"<image>\nWhat's so funny about this image?"}],
    tokenize=False,
    add_generation_prompt=True,
)

image_path =  "./assets/image.png",
output = generate(model, processor, image_path prompt, image_processor, verbose=False)

What do you think?

Great, integrating get_model_path into load and config into load_image_processor will reduce the overhead quite a bit. Looks good!

This was already done a day ago ✅  https://github.com/Blaizzy/mlx-vlm/pull/7


Improvement for errors.

Hi, I'm getting an error on the server side:
Your app is crashing. Here's the latest log.

=> Errors prevented startup:

While Building the application:
sk8earth.jade: Jade syntax error: Unexpected token ILLEGAL

=> Your application has errors. Waiting for file change.

It's not so helpful though, as it doesn't say what file and line. It'd be nice if you could add those features. :D

@mquandalle Are line numbers there now? I just got back into development of my Meteor app, so I'll for sure come across some errors at some point. xD

+1 for this one.
On bigger files, it would make it much harder to debug. This is sadly a deal-breaker for me now, although I love jade.

+1
There is a try { block wrapping the compiler call, which tries to make the output exception prettier, but I think it works a bit counter to the intention behind it.


azure-mgmt-costmanagement CostManagementClient does not handle api_version

Package Name: azure-mgmt-costmanagement
Package Version: 1.0.0
Operating System: Linux
Python Version: 3.7.3

Describe the bug
The default api_version used by CostManagementClient  is incorrect (https://github.com/Azure/azure-sdk-for-python/issues/16102, https://github.com/Azure/azure-sdk-for-python/issues/17351). When I specify the correct API version explicitly while constructing CostManagementClient , it is ignored.
To Reproduce
Steps to reproduce the behavior:

CostManagementClient(api_version='2019-11-01')
attempt to use this client
observe it failing because it uses the wrong API version anyway

Expected behavior
I expect that when I specify an api_version string when constructing CostManagementClient , that API version is used.

@jazelenk Thanks for your question! Directing it to the people who can answer it.

Hi @service team, 'azure-mgmt-costmanagement'==1.0.0 according to tag (https://github.com/Azure/azure-rest-api-specs/tree/master/specification/cost-management/resource-manager#tag-package-2020-06). However, in issue 'https://github.com/Azure/azure-sdk-for-python/issues/16102', customer gets the following error which indicates that '2020-06-01' is not supported. Could you help to check it?
azure.core.exceptions.ResourceNotFoundError: (InvalidResourceType) The resource type 'Query' could not be found in the namespace 'Microsoft.CostManagement' for api version '2020-06-01'. The supported api-versions are '2018-05-31,2018-08-31,2018-08-01-preview,2018-10-01-preview,2018-12-01-preview,2019-01-01,2019-03-01-preview,2019-04-01-preview,2019-05-01-preview,2019-10-01,2019-11-01'.

This is not the same issue as #16102. That issue is about the default api_version being incorrect. This issue is about CostManagementClient ignoring the api_version kwarg.

(1) 'azure-mgmt-costmanagement' is single-api package. Its api version is hardcoded and can't be changed anyway.
(2) The problem is a service problem. They merge swagger of '2020-06-01'(https://github.com/Azure/azure-rest-api-specs/tree/master/specification/cost-management/resource-manager/Microsoft.CostManagement/stable/2020-06-01). Howerver, it seems that '2020-06-01' is not supported until now.

@jazelenk  It may take long time to wait for service deployment. How about that : we publish a new package with older api-version '2019-11-01'.
Please check whether the private package works well:https://portal.azure-devex-tools.com/api/sdk-dl-pub?p=Azure/14584/azure-sdk-for-python-track2/track2_azure-mgmt-costmanagement/azure_mgmt_costmanagement-1.0.0b1-py2.py3-none-any.whl. If it works well, we will publish it next week. (please ignore the strange package version)

This issue is not about the problem API version; the issue for that is #16102. This issue is about the fact that CostMangaementClient silently ignores the api_version kwarg. Neither updating the CostManagement RP nor updating the swagger fixes this issue.

please pay attention to my comment before:

Anyway, we have merged the PR (https://github.com/Azure/azure-rest-api-specs/pull/14584) to revert to older API. If https://portal.azure-devex-tools.com/api/sdk-dl-pub?p=Azure/14584/azure-sdk-for-python-track2/track2_azure-mgmt-costmanagement/azure_mgmt_costmanagement-1.0.0b1-py2.py3-none-any.whl works well, we could publish new package for you.

new package for '20219-11' : https://pypi.org/project/azure-mgmt-costmanagement/2.0.0/

What further information is required?

Sorry! I missed the previous messages back in May. :-( I tested with that package, and unfortunately the api_version argument is  still silently ignored.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.10.44",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=42e49001380989f757f17045cf352dff9ae124b3"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "42e49001380989f757f17045cf352dff9ae124b3",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "bonding: init notify_work earlier to avoid uninitialized use\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.44 by commit 42e49001380989f757f17045cf352dff9ae124b3. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1000939


[Question] Micro in RAW mode

Is there any more info to find somewhere about "raw" mode in Micro which is helping to discover Key Binding as it's seen by Micro ?

for example, some keys are reported as "KeyEvent: .."
some as "KeyRaw: ..."
and some as "KeyPaste: ..."

what is the difference between them all ?
which sequences are "allowed" to be used for key bindings, and which are not ?
micro 2.0.6
Thank you in advance !
Rgds, -Dimitri

I'm not exactly sure what sort of information you are looking for. Key events occur when micro receives a sequence from the terminal that micro knows corresponds to a certain key. For example, micro knows that if the terminal sends \a, this corresponds to the user pressing Ctrl-g, so a Ctrl-g key event will be emitted when \a is received from the terminal.
Raw events occur when micro receives an escape sequence from the terminal that has been specifically bound by the user in the bindings file. The escape sequence bound in a raw event must begin with \x1b (the escape character).
A paste event occurs when micro receives pasted text from the terminal. If the terminal supports bracketed paste, and the user performs a paste through the terminal (for example Ctrl-Shift-V in gnome-terminal), the terminal will send \x1b[200~...\x1b[201~, where ... is the pasted text. Micro will parse this and return the text as a paste event. If your terminal does not support bracketed paste, the terminal will just send the paste text as a chunk of characters, and this may or may not be interpreted as a paste event or instead a series of key events depending on what the paste option is set to.

Thank you ! this is now much more clear !
few more questions then :

any reason the key raw events to be accepted as key binding must absolutely be starting by Esc (\x1b) ?
also, for ex. micro reports a key press as "Ctrl+]" (and \x1d) in raw mode, but when I try to bind "Ctrl-]" or "\u001d" in bindings.json file, they seems to be just ignored or not recognized, any reason ?

Rgds, -Dimitri


VSCode mishighlights format!("{:x?}", a)

This is probably related to the aging grammar being used for highlighting, but I've seen that there's been work on putting a better grammar into the rust-analyzer extension, so I think this belongs here?
rust-analyzer version: 2020-10-26 (eae54b5); VSCode extension 0.2.360; VSCode 1.50.1

Hi @lf-,
Could you clarify:

Is this happening with Rust Analyzer enabled, or with the built-in VS Code grammar?
Is semantic highlighting enabled or disabled?
Could you post a larger code snippet, rather than a screenshot?

Sorry about the tiny screenshot! It was in semi-closed code so I was uncomfortable revealing much code, but I have reproduced it in the below snippet:
#[derive(Debug)]
struct Thingy(u8);

fn main() {
    let thingy = Thingy(17);
    let mut n2 = 0;
    n2 += 1;
    println!("{:x?} {} ", thingy, n2);
}

Here's a screenshot of it happening in this smol snippet:

I think I have the rust analyzer grammar since rust analyzer is doing its magic.

Semantic highlighting is enabled, if that's what makes mut variable uses get underlined.

:)

Seems to reproduce for me:


Time Skipping Service

What was changed
Test Service gRPC service is added with time-skipping methods.
JavaSDK is fully reworked to use Time Skipping gRPC Stubs instead of accessing the in-memory TestService internal instances and classes directly when time skipping functionality is needed, reducing coupling between SDK test classes and test-server implementation.
Native Test Service default starting behavior changed to start with locked (disabled) time-skipping to behave closer to a real Temporal Server by default.

@bergundy This is the most important for you for time-skipping in typescript: https://github.com/temporalio/sdk-java/pull/1076/files#diff-d7a107df90fe446efc696d828e3df42e829262e802060ade229d4cdddbb6fb26R41

@Sushisource @mmcshane completely reformulated docs on TestService (https://github.com/temporalio/sdk-java/pull/1076/files#diff-d7a107df90fe446efc696d828e3df42e829262e802060ade229d4cdddbb6fb26R39)
Please check if this more formal definition makes more sense.


Fix assertion strategy to accept claim key overrides, allow grant type overrides, and remove assertion_type and scope from headers

These code changes were necessary before we could use Google's oAuth2 two-legged APIs with a service account.

scope needed to be part of the assertion, not in the headers.
The string 'urn:ietf:params:oauth:grant-type:jwt-bearer' was set as the :assertion_type header, when it needs to be :grant_type.  Google blows up with :assertion_type in the header.
Google wants the timestamp for when the assertion was issued (:iat) as part of the claims.
The :prn claim key needs to be optional, if you want to make a request as the service account not on behalf of a user.

From https://developers.google.com/identity/protocols/OAuth2ServiceAccount:

Wow!  @josephpage sorry, this github notification must've gotten completely buried.  I'd be happy to take a look.

I would be super interested in adding a code example for this specific use case to our wiki as well.  This is a common need that Google has failed to adequately address in their own help tools and documentation, IMO.  I think there are a fair number of people wondering how to accomplish this with a service account (me being one of them).

@pboling good to know.  FWIW we've been using this gem with the added contents of this PR to support both 3-legged and 2-legged OAuth with Google for a while now (haha about 2.5 years I guess!) and it's been rock solid.  I have some time booked on my calendar to give this PR some attention -- I'll try to include some documentation and whatnot as well.

Alrighty!  I just spent a few hours reading RFCs and all kinds of fun things.  I'm currently working on making sure the branch still works with Google, but I'm slowly giving the entire Assertion class an overhaul.
Learnings include:

Apparently when we implemented Google OAuth2 a few years ago, they were still using the prn claim key to indicate 'principal' -- i.e. "the person on behalf of whom you are requesting access via a service account".  This concept, at some point, was apparently renamed to sub, for 'subject'.  (I double-swear though that the Google service account docs at the time had prn in them)  The spec confirms this:

4.1.2.  "sub" (Subject) Claim

   The "sub" (subject) claim identifies the principal that is the
   subject of the JWT.  The claims in a JWT are normally statements
   about the subject.  The subject value MUST either be scoped to be
   locally unique in the context of the issuer or be globally unique.
   The processing of this claim is generally application specific.  The
   "sub" value is a case-sensitive string containing a StringOrURI
   value.  Use of this claim is OPTIONAL.

One of the reasons we ran into a fundamental conflict in this file vs what will work with Google is the fact that some of the claim keys that needed to be in the JWT were mysteriously in the header.  (e.g. scope)  I remember finding this very confusing.  Google blows up if you send your requested scopes in the header, but it turns out that totally is a valid use case per the spec:

   In some applications using encrypted JWTs, it is useful to have an
   unencrypted representation of some claims.  This might be used, for
   instance, in application processing rules to determine whether and
   how to process the JWT before it is decrypted.

   This specification allows claims present in the JWT Claims Set to be
   replicated as Header Parameters in a JWT that is a JWE, as needed by
   the application.

In order for Google to work, there were some keys that are currently just straight up not present in Assertion#build_assertion.  The only claim keys that can be encoded right now are:

{
  :iss => params[:iss],
  :aud => params[:aud],
  :prn => params[:prn],
  :exp => params[:exp]
}

Google specifically asks for iat ("issued at"), and scope (which, mentioned previously, was in the headers instead).  Their example:
{
<EMAIL_ADDRESS>  "scope":"https://www.googleapis.com/auth/devstorage.readonly",
  "aud":"https://www.googleapis.com/oauth2/v4/token",
  "exp":1328554385,
  "iat":1328550785
}

Curious what the 'allowed' claim keys were, I went digging around and came up with the official list.  Given that there are a lot in there (and presumably allowed to be even more), the build_assertion strategy should probably just pass through whatever the heck arbitrary claim keys anybody would like to assert.
In addition, another of the difficulties we ran into in this file was the fact that prn was always included in the JWT.  That's one of the differentiating factors with Google's OAuth:

So, always including sub (née prn) in a claimset will work as long as you're always trying to do 2-legged service account stuff -- but the minute you try to do a thing for a regular old 3-legged<EMAIL_ADDRESS>account, Google blows up because of course that user doesn't have the ability to issue a domain-wide enterprise approval for scopes or do any kind of service account request-on-behalf-of nonsense.  This is why the current state of this PR only includes prn in the claimset if the params contain the key prn, instead of leaving it around as a nil-value key.

Conclusions:

This PR as it stands currently will break anybody using the existing (valid!) behavior of including scopes in the header.  I am resolving that currently.
If some claim keys need to not be there always, and literally maybe any string is allowed to be a claim key, build_assertion should probably just assemble a hash from the params and use whatever keys somebody wants.  I am also resolving this currently!

Stay tuned for an update on this PR; I've just finished resolving merge conflicts and all that.

Another mystery solved!
Right now on master, this gem sends:
:assertion_type => 'urn:ietf:params:oauth:grant-type:jwt-bearer'

In order to get Google to work, we had to change it to:
:grant_type => 'urn:ietf:params:oauth:grant-type:jwt-bearer'

Exact same value, but with a different key name.  Turns out: when this file was written, assertion_type was accurate as of OAuth2 draft v10.  However . . . it was changed to grant_type in draft v11.
From the final RFC (which indeed makes no mention of assertion_type):
   o  Parameter name: grant_type
   o  Parameter usage location: token request
   o  Change controller: IETF
   o  Specification document(s): RFC 6749

This will be a breaking change, but I believe that assertion_type will be simply incompatible going forward.

I think that a breaking change for an implementation supporting a "draft" standard is acceptable in a minor patch, because you can also see it as a change to maintain compatibility with the RFC as it became finalized (i.e. not doing the change could be considered a bug?)
What do others think?  I think it would be OK to include this in the planned 1.5.0 release.

@pboling I agree that it would be considered a bug at that point... Sounds good to me.

@pboling / @galois17 thanks!  Also: I've immediately run into a larger existential question here, with regards to assertion.rb.
If, per the JWT spec, any arbitrary key is totally allowed to be a claim key, and if also per the spec any arbitrary key is totally allowed to be in the header (a la scope) . . . it would seem that the current way of initializing the Assertion strategy object is somewhat incompatible with the RFC.
Right now, you call client.assertion.get_token(params) -- where params is a hash passed to all subsequent methods.  How can we tell which keys of that hash are intended for the header, and which keys are intended for the JWT?
For example: in master right now, params[:scope] will be stripped out and put into the header.  However, in some situations (i.e. Google), params[:scope] will need to go into the JWT claimset.  In yet other situations, you could have both.
In addition, there are some other certain 'special' keys of the params hash (e.g. params[:hmac_secret] that are used for other purposes entirely.  Haha if there ever ended up being a legitimate claim key that somebody needed to send named hmac_secret, I daresay it would be a problem.
The easy button is for get_token to take multiple hash arguments (i.e. a headers hash that is totally separate from the claims hash) . . . but this would obviously have the side effect of a breaking change for anybody currently using this.  In addition, there is currently a secondary opts = {} arguments already in existence, and it usually ends in maximum weirdness to try to have multiple empty-hash-defaulting arguments next to eachother, let alone introduce new ones.
To that end, to preserve backwards-compatibility, I propose breaking the params argument into two top-level keys:
params = {
  :headers => {},
  :claims => {}
}

Backwards compatibility can be preserved by intercepting other top-level keys of params and interpreting them the way current master does.
This does have the downside of affecting the other methods (build_request and build_assertion) in this file, but:

Those methods do not seem to be called anywhere else in this gem
Neither of those methods had tests until we added them in this PR.

To that end, I am going to modify their arguments a little and also make them private.  This could be a breaking change to anybody calling those methods directly from their application, but those methods seem inherently 'private' in their intent, given what this object is trying to accomplish.

I like your ideas.  One idea would be to parse the params hash split to headers and claims as done now, by default, and to allow specification of an array of keys in opts[:headers] for which of the keys go to :headers and opts[:claims] for which of the keys go to :claims.  That has the advantage of easily allowing a key to be used in both headers and claims without the user needing to stick it in both places.  Maybe that's not really an advantage though?  🗡

Thanks!  Stylistically, totally agreed -- however, I tried playing around with putting stuff like that in the opts arg . . . the issue I ran into is that right now, opts does affect anything having to do with building the request/assertion stuff.  It gets passed directly into OAuth2::Client#get_token as the arg "access_token_opts".
If folks are currently using that opts hash expecting it to be all stuff pertaining to wrangling access tokens, I'm not sure A.) in what ways people might be using it right now, and B.) what things we might break by having certain special keys that get ripped out of it.
I'm going to pursue this nested key structure thing and see how it ends up looking . . . haha if it ends up being completely ridiculous I'll go the other route.

Ah, yes.  The ripping out keys unexpectedly is a real concern.  Thanks for re-mentioning that, the import hadn't fully clicked the first time!

Ok, I am back on this today.  More learnings:
The current behavior of the params[:scope] argument is not what I thought it was doing.  It is not getting put into the JWT headers.
Currently, params[:scope] is getting put into the raw request params.  E.g. right now, let's say you passed in a params hash of:
{ :iss => 'aaa', :aud => 'bbb', :scope => 'ccc' }

:iss and :aud would get packaged into the JWT claimset, and then the client would send a POST request to the token endpoint with a body of: assertion=blahblahblah&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&scope=ccc
I had no idea why this would be a top-level request parameter, and like even if the key isn't passed in, I'm pretty sure right now in master an empty scope= is tacked on to every single token request made by the gem.  And there were no tests for that behavior.  I was about to just remove it, but . . . I went digging and found (yet another!!!) RFC.  In particular, RFC 7521 describes:
scope
      OPTIONAL.  The requested scope as described in Section 3.3 of
      OAuth 2.0 [RFC6749].  When exchanging assertions for access
      tokens, the authorization for the token has been previously
      granted through some out-of-band mechanism.  As such, the
      requested scope MUST be equal to or less than the scope originally
      granted to the authorized accessor.  The authorization server MUST
      limit the scope of the issued access token to be equal to or less
      than the scope originally granted to the authorized accessor.

So I think this means a couple things:

Because this is an optional request body parameter per the RFC, and there were no tests for the current gem behavior of it always being there, I'm going to remove this behavior and only put the parameter in if there is a passed-in value.
This means that what I thought scope was doing (getting put into the header of the JWT) was not actually happening . . . that means there is in fact no current functionality that lets you put stuff into the JWT header.  In fact, if you look at the jwt gem's encode arguments:

def encode(payload, key, algorithm = 'HS256', header_fields = {})

Assuming those arguments are named in a sane manner . . . we've only ever passed in three arguments to that method.  I don't believe we've ever had a way to pass in header fields!
And so while that is interesting and I believe should also be added, I'd like to keep this PR from getting even larger -- and I believe 'adding JWT header field functionality' would be a nice compartmentalized followup PR to make once I'm done with this one.

Then with your changes, it will still add the scope param to the URL when scope is passed in params, but otherwise not add it to the URL, right?
That sounds logical to me, and appears to be in line with that optional RFC. 👍

@jhmoore Does/Will your PR obviate the need for this other JWT related PR, which also change prm to sub?  https://github.com/oauth-xx/oauth2/pull/198/files

Aha!  Yes, although mine goes about it in a slightly different manner.  That one passes through params straight through to the claimset (and certain keys like hmac_secret or scope are 'special'), whereas this passes params[:claims] to the claimset.  Now that I've gotten really into this: most of the fundamental incompatibility this file has with Google is the fact that they require a claim named scope -- which directly collides with the concept of params[:scope] here.
While we're on the topic: if this is going to be a 2.0.0 breaking change release . . . I'm less opposed to breaking the signature of this method's arguments.  Simply adding another argument to get_token would certainly be cleaner than doing a nested hash.  What do you think?

Yes, let's go with the breaking change and the better design. 👍

This will fix https://github.com/oauth-xx/oauth2/issues/203

@jhmoore If you have some time please also review this PR.  I think it is addressing some of the same things.  I'm interested to know if your work here will allow us to close that (stale, conflicted) PR.

@pboling yep you are correct, you can close that one.

@jhmoore One more!  https://github.com/oauth-xx/oauth2/pull/198/files
Does that one also get obviated by this PR?

@pboling :+1: indeed, that one too!

@pboling take a look -- there's still some cleanup I'd like to do, and I need to do a full rewrite of the description of this PR, but https://github.com/oauth-xx/oauth2/pull/220/commits/34c37814f68810423eba7cbe1598a70037ff7b36 is effectively what I'm proposing in terms of argument structure changes to get_token.  I'm not the biggest fan of having two consecutive opts = {} arguments, but the way that those things are used are so drastically conceptually different, I didn't really want to combine them.
I'd also appreciate a review of the documentation comment changes -- I attempted to emulate the style in other files, but haha I've never used this YARD thing before so I have no idea how successful I was.

This is also my first time on the YARD.  I'll review later tonight.

Just need to get the build passing before we can merge.

Yeah, was just looking at that.  Appears to be entirely Rubocop . . . . including some rules I disagree with on a deep philosophical level (e.g. Do not use expect in before hook) but haha this is not my project.  Will work on that now.

Oh, boy.  Haha one of the rules is RSpec/NestedGroups: Maximum example group nesting exceeded [5/3].  I can alter the specs, but it's going to make the organization much worse.  Given the specs look good to you, is it alright if I disable that rule?
Also: both Rubocop and Code Climate are angry with the new method having 5 arguments.

Oh this is interesting: one of the Travis builds is failing for reals.  https://travis-ci.org/oauth-xx/oauth2/jobs/351559454
Specifically, jruby-1.7.27 is blowing up and unable to call JWT::Decode in the specs.  The other versions of jruby appear to be fine.  Haha I know next to nothing about jruby version minutiae . . . any thoughts?

It appears to be some issue with referencing JWT::Decode directly in the spec?  Curiously, the call to JWT.decode seems to work fine.
The question of when require-ing a module in a spec, why one specific version of jruby cannot access a class in that module's namespace (despite other versions of jruby being able to access that class just fine) is a keening maw of madness I don't really feel like spelunking into on this particular Friday afternoon, so I just changed the specs to all use JWT.decode instead.

Yeah, let's disable that RSpec Rubocop validation.  RSpec/NestedGroups: Maximum example group nesting exceeded [5/3].  I tend to like highly contextualized specs as well.  I'd love to be able to have simple objects to test that only do one thing with little context required... but the world is not that simple, and getting things to be that simple is... complicated. 💃

@pboling alrighty, take a look.  I am not wild about the format of get_token(hash, hash, hash, hash), but Rubocop and Codeclimate both were rather insistent about a maximum of 4 arguments in a method.
This method is taking in a lot of different conceptual things.  One option might be to have Assertion itself be initialized with the claims and encoding options -- i.e. the concept of "an assertion" seems like a thing that would be initialized with its JWT ready to go, and "get token" seems like an instruction that would take that assertion and send it to be exchanged for a token?  However, Assertion inherits from Strategy::Base which establishes a shared bit of superclass instance magic . . . no other strategy type seems to override def initialize.
But yeah, Client#assertion could be modified to take in some args and pass them to the initialized strategy object; usage in that case would be more like:
client.assertion(claims, 'HS256', 'secret_key').get_token(opts)

Anyway, this PR as it stands right now will work (and I've updated the PR description for the current state of things), but I am open to suggestions.  Haha I guess it depends how closely-shorn we want to groom this particular yak.

Approved, but would like this line of documentation tweaked: https://github.com/oauth-xx/oauth2/pull/220#discussion_r174033859

@pboling agreed . . . when a method has multiple hash args and one of them is optional, I agree that I kinda always want curlies regardless of whether or not I'm passing in the optional one.  Hilariously --
being a believer of the whole 'tests as documentation' thing, I did have it like that, along with the test setup.  However, rubocop blows up with:
Offenses:

spec/oauth2/strategy/assertion_spec.rb:69:37: C: Style/BracesAroundHashParameters: Redundant curly braces around a hash parameter.
          subject.get_token(claims, {:algorithm => algorithm, :key => key})
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Militant elegance at the expense of clarity!  :rage1: Haha anyway, tests are left in the state of rubocop passing; comment is updated as you suggested.

Thank you @pboling and @jhmoore - I know this was a big one!

👍Thanks for reviving this gem!
It might take me a bit, but now that this stuff is merged and the changes solidified, I'll work on documentation of the Google service account use case.

That would be most excellent!


Text element change is sometimes not persisted

Bug Description
The text element sometimes returns to its old value, e.g. when clicking on the workspace (works when clicking in elements/inspector panel).
Expected Behaviour

Steps to Reproduce

Screenshots

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria
QA Instructions

The bug was introduced here: https://github.com/google/web-stories-wp/commit/21551aedf751a39f17337c665ddd966fedec5dc8.
Looks like the underlying issue is here.
Sometimes relatedTarget will be null (it's normal), more details:
https://developer.mozilla.org/en-US/docs/Web/API/FocusEvent/relatedTarget
Removing evt.relatedTarget &&  should do the trick @barklund can you see any potential issues with that?

I looked at it more thoroughly, here is what I found:
The bug was introduced here: https://github.com/google/web-stories-wp/commit/21551aedf751a39f17337c665ddd966fedec5dc8.
^Could work with useFocusOut onFocusOut but because relatedTarget can sometimes be null (and it's normal, more on that here) this line will not work and the callback will not be called (which saves the text).
You might ask why useFocusOut onDocumentClick will not work? - the textBox is unmounted (and listeners removed) when you click outside so that part is never executed (not like in case of e.g. Dropdown).

I'm wondering if we should revert onFocusOut (or bring back the onMount along with onFoucsOut). And we can go straight to a more stable solution. Which, I expect, would be a callback in the useEditingElement when the editing element ID changes (to a new element, or via clearEditing). Something similar is done in the design panel and it's pretty stable.

I was thinking about how useFocusOut should work, right now we detect focusout and outside click, the missing piece is: what to do when the element is removed.
In Chrome when you remove the element that was focused, blur/focusout will be fired (not working in FF bug here). With React we can achieve something like this by utilizing the "unmount event".
Would adding callback() in useFocusOut clean-up function cause any issues?
I can see it fixes this bug and works with dropdown/datepicker.

Would adding callback() in useFocusOut clean-up function cause any issues?
I can see it fixes this bug and works with dropdown/datepicker.

I think that's a safe fix here, yes. It seems reasonable, that unmount is comparable to focus out and should always do the same thing (for text fields: save the content).
For the other situations, we use it to remove the element on focus out, which means that unmount already did what we wanted anyway, so no harm done.
@merapi, 👍 from me.


MisMatch between labels during dataPrep v.s. during inference

I might be missing something, but it seems there is a mis-match between the label ordering when preparing the training data v.s. when doing the inference in the provided jupyter notebook.
In the 'datasets.py' file, in the 'transform_labels' method, the order is: "dict_labels = {'positive': 0, 'neutral':1, 'negative':2}"
But in the notebook:  "labels = {0:'neutral', 1:'positive', 2:'negative'}"
In both cases, 'negative'=2, but 'positive' and 'neutral' are switched.
Is there a reason I am missing?
Thank you!

Thanks for pointing it out. The transform_labels method in the dataset.py is used to prepare a different dataset (financialPhraseBankDataset), and it's not used by the inference Notebook code. If you use our notebook, I assume you want to use the model fine-tuned by the analyst-tone data, where the labels are {0:'neutral', 1:'positive', 2:'negative'}


Quizzes Events Deprecations

These events will be deprecated per Release Notes...
I see no reason to clean this up before the release, and will deprecate the schema/parser after the release date.
https://community.canvaslms.com/docs/DOC-18049-canvas-release-notes-2019-12-21#jive_content_id_Live_Events

Group Events Deprecations
Events in the following groups have been deprecated and will be removed on 2020-02-18:
Quizzes Next Quiz
Quizzes.item
Quizzes.quiz Clone Job
Quizzes.quiz
Quizzes.quiz Session
Quizzes.qti Import
Quizzes-lti.grade

This was deprecated in Data Services (Canvas). The subscriptions for these events are no longer available. I will remove them from the schema at the end of school year.


separate cyclone/oidc authn methods

Split the cyclone and oidc authn methods to allow their behavior to be different when creating new accounts.

Modify the OIDC authn method to use the email address as the account username.  Optionally provide the user's real name if it is provided in the received claims.

The roles (groups) will come in the claims from Keycloak as the :roles (:groups) key. The roles will be prepended already with the realm name.  The groups will also be prepended to the full group path.  Nuvla will have to parse this to provide separate group names for each level of the hierarchy.


Fix panic when diagnostics are at the end of a file and misaligned hints

If the range of a diagnostic ends at the end of a file, a panic happens.
Minimal example:
main.typ:
mispelled

Now run typst-lt check main.typ and the following error occurs:
thread 'main' panicked at /home/skadic/.cargo/registry/src/index.crates.io-6f17d22bba15001f/annotate-snippets-0.9.1/src/display_list/from_snippet.rs:286:9:
SourceAnnotation range (11, 11) is bigger than source length 10

If we add a newline to the end of the file, we do not get a panic, however the output is:
info[MORFOLOGIK_RULE_EN_US]: Possible spelling mistake
 --> main.typ:1:1
  |
1 | mispelled
  | --------- info: Possible spelling mistake found.
  |

The hints suggesting replacements are missing here. If we add another newline:
info[MORFOLOGIK_RULE_EN_US]: Possible spelling mistake
 --> main.typ:1:1
  |
1 | mispelled
  | --------- info: Possible spelling mistake found.
2 |
3 |
  |  help: Misspelled
  |  help: Dispelled
  |

The hints now appear, but are misaligned (2 lines down).
The source of this issue is this line in this snippet of output.rs:
for replacement in &info.replacements {
	let pos = start_buffer + info.length + 2;
	annotations.push(SourceAnnotation {
		label: &replacement.value,
		annotation_type: AnnotationType::Help,
		range: (pos, pos),
	})
}

pos can extend beyond the length of the input, leading to a panic or the hints not being shown. If the + 2 skips over newlines, then the hints end up being misaligned, being shown up to 2 lines below the actual diagnostic as shown above.
My change fixes the panic and prevents pos from skipping newline characters. After my change, the outputs for all the above cases is:
info[MORFOLOGIK_RULE_EN_US]: Possible spelling mistake
 --> main.typ:1:1
  |
1 | mispelled
  | --------- info: Possible spelling mistake found.
  |          help: Misspelled
  |          help: Dispelled
  |

Looks good, thanks for the fix.


Extra Images cannot be fetched from fanart.tv

What TMM version are you using?
2.9.14 (also doesnt work on 2.9.13)
release, pre-release, nightly, or directly from GitHub/branch?
pre-release (also affects release)
What is the actual behaviour?
Throws out internal server error when searching for extra images (clearlogo, banner, clearart, etc), most likely due to ssl
What is the expected behaviour?
Bring up images into the fields above
Steps to reproduce:

Right click media and click edit movie
Click extra artwork
click any field
4, Nothing shows up unless you paste in a link to an image

Additional
Have you attached the Logfile from the day it happened? - Yes
Your Operating system? (win/mac/linux? version?) - Windows

tmm.log

well, what should we do if fanart.tv servers throw a HTTP 500 error?

I'm guessing it was just on their end since it wasnt working yesterday and just this-morning it just started working mysteriously


Captions to images from local file

Thank you for the fantastic plugin.
I'm currently trying to add captions to local images but couldn't find any information on how to do this in the documentation. Here's an example of what I'm working with:
![[images/4bb739f705fd6edbb710dfcb05332bb0_MD5.jpeg]]
![[images/41647269cc2b8bea84d68ccf3560efd6_MD5.jpeg]]

I found same question here https://github.com/vertis/obsidian-image-layouts/issues/11#issuecomment-2066981982

I apologise for the slow response. This file details how to add text: https://github.com/vertis/obsidian-image-layouts/blob/main/docs/text.md
The long and short of it is that "Caption" is a singular for the whole layout and descriptions overlays over each image, you would provide one for each image in the set.

In my experience, using the "" format seems to only work for external files. The exact same structure with local files instead shows "Image 1", "Image 2", etc as descriptions.
The frontmatter method doesn't work with either, the description fields don't show up at all.

Experiencing the same. Documentation is rather bare in regards to certain instances. All I see for local images is "Image 1" "Image 2"

This works for me
(agree that the doc could be clearer)
```image-layout-a
---
descriptions:
- Soundwave
- Carbon Black
---
![[lsx-ii-soundwave.png]]
![[lsx-ii-carbon-black.png]]
```

Giving this:

Would be nice to see the ![[my-image.png|my description]] format supported though!


Uploaded

how would we upload using ftp client cause my host does not support composer

Here is an issue with more information about running without Composer: #16
But again: this tool is designed to be used with Composer. If you are unwilling or unable to use Composer, do so at your own risk.
This issue section is intended for questions or problems regarding this API client. If you cannot understand that, I'll be forced to ban you from opening more issues.


Icon white background

To make the satellite-map button more visible, it would be better to display the stack icon on white background.

I added the SVG to the asset stack. Please check whether it works and re-open if necessary @NinaWie


[OF-1148] fix: Parse breaking changes

move breaking changes to top of release notes
fix bug causing all tickets to be no tickets
stop merges from being added to misc changes

connected-spaces-platform Pull Request
For the reviewer

[ ] If required, are the changes covered by appropriate tests?
[ ] Are any public-facing API changes well documented?
[ ] Is the code easily readable and extensible and/or follow existing conventions?

Current output
README.md

Latest README.md


Horizontal scrolling is not blocked

It's a bug or a feature ?

I noticed that too during testing with the keyboard. I am not sure how I managed to scroll sideways, I did not manage to reproduce consistently.

fixed in 2f4412d

PR: https://github.com/readium/readium-desktop/pull/439

I am not able to reproduce this bug. Any tips?
(MacOS)


Can you add level in server (same agar.io)

Can you add level in server (same agar.io) 0-100 lvl

DUPLICATE.
.
.
.
.
NO!

Check #457 out

@vincent95330 *

client sided?

client sided?

Both server and client @Jhair2015


Closing the plot in plotConvertedBlock()

What is the change?
Here I simply added a plt.close() line inside a plotting function.
Why is the change being made?
Leaving plots open can cause havoc with anyone else trying to use matplotlib elsewhere in the ecosystem.
close #1904

Checklist

[x] This PR has only one purpose or idea.
[x] Tests have been added/updated to verify any new/changed code.

[x] The code style follows good practices.
[x] The commit message(s) follow good practices.

[x] The release notes have been updated if necessary.
[x] The documentation is still up-to-date in the doc folder.
[x] The dependencies are still up-to-date in pyproject.toml.

@keckler I will have to test this downstream. TBD


Job class status

Job class was added to split pdf job's status, and added internationalized strings for job classes.

Note:
Instead of adding the job class to the session I figured it's easier if I updated the status before the job is queued (so I also avoid the nil class error when calling it on the JS poll_job side).
Also I need to make similar changes to the generate job / other jobs, which I can do in a separate pull request.

@rathukugan now that the infrastructure is in place, choose a better progress message for the job than "x out of y" -- the latter can remain as a default, should in general shouldn't be used.
Also make use of the other flash keys (besides just :success) when sending back the status.


Add More Tests

Codecov Report

Merging #41 (7ab9250) into master (8ba1c15) will increase coverage by 0.45%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
+ Coverage   30.15%   30.60%   +0.45%
==========================================
  Files          11       11
  Lines        1101     1101
  Branches      126      126
==========================================
+ Hits          332      337       +5
+ Misses        756      749       -7
- Partials       13       15       +2

Impacted Files
Coverage Δ

src/dredge_logger/Log.py
40.22% <0.00%> (+5.74%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ba1c15...7ab9250. Read the comment docs.


Could you tell me how to get the black mask like hair.png. Thanks a lot! My experiment results of mask is colourful

f

Have you already solved this problem？Could you tell me how to do it？Thanks sincerely.

save question!!!!!!!!!!!!!

您的邮件我已收到。祝一切顺利！

您的邮件我已经收到了。祝一切顺利！

Hello, I have the same problem. How did you get the black mask？

您的邮件我已收到。祝一切顺利！

@yql0612 @an-zi-li  @shenhaiyoulan Have you already solved this problem？Could you tell me how to do it？Thank you so so much!!!

Hello, I have the same problem. How did you get the black mask？

It is not a black mask; it is simply mask data. The reason it appears "black" is likely because the ID for the component falls between 0 and 12, assuming there are 13 components. Since the pixel values of an image range from 0 to 255, the mask data appears black when visualized as an image.


Add post_process_script_function method

Previously, there was no definition for the post_process_script_function method. This commit adds the method to the codebase, which allows for post-processing scripts to be run on preservation packages. The method takes two parameters: the path to the preservation package and the result code of the pre-processing script.

Closing. Will re-do this change in another branch


Canont install wasp, there no executable file in bin

When I finish the instructions, there is nothing in ~/wasp/build/bin/
mkdir build
cd build
cmake ..
cmake --build .

The executables are written into the subdirectories, e.g.
~/wasp/build/src/tools/wasp


[Fix] Fix id null and bump version

@johnmcaliley
Description
Related to #292, I made this PR for fix the crash error when id is null.
And I found that the master code different with my current gem file code. So, I bump the version of this gem for trigger bundle update.
Anw, I wish become maintainer for this repo. 🧀

I noticed we have a couple of PRs related to method. I'm going to close this one out in favor of #295


Add functionality to return just a data frame rather than a list

Currently the API call functions built into the Rnssp package return a list rather than a data frame (or image). Users are still required to extract the data frame or image from the list for each API call, a step that could be wrapped into the existing API call functions. This would require fewer lines of code for users to write, reduce the chances of error, and make the package and APIs more user-friendly.
Below is a suggested function that would return the final result from each type of API call (including visualizations). Arguments have been made in the past that if the API structure changes, functions like this would no longer work, but if that does happen then users will have to update all of their code to match the new structure. This way, any updates in the API structure can be accounted for in this function, and as long as users update the package they will be able to use the function to call the API and get the output they need.
The function below is based on the code found in the Rnssp_intro vignette (https://cdcgov.github.io/Rnssp/articles/Rnssp_intro.html) prior to the addition of the newer API call functions.

get_essence_data <- function(url, start_date = NULL, end_date = NULL) {

  api_type <- str_extract(url,"(?<=api/).+(?=\\?)")

  url_new <- change_dates(url, start_date, end_date)

  if (api_type == "timeSeries") {
    api_response <- myProfile$get_api_response(url_new)
    api_response_json <- content(api_response, as = "text")
    api_data <- fromJSON(api_response_json) %>%
      extract2("timeSeriesData")
  } else if (api_type == "timeSeries/graph") {
    api_png <- myProfile$get_api_tsgraph(url_new)
    knitr::include_graphics(api_png$tsgraph)
  } else if (api_type == "tableBuilder") {
    api_data <- myProfile$get_api_data(url_new)
  } else if (api_type == "tableBuilder/csv") {
    api_data <- myProfile$get_api_data(url_new, fromCSV = TRUE)
  } else if (api_type == "dataDetails") {
    api_data <- myProfile$get_api_data(url_new) %>%
      extract2("dataDetails")
  } else if (api_type == "dataDetails/csv") {
    api_data <- myProfile$get_api_data(url_new, fromCSV = TRUE)
  } else if (api_type == "summaryData") {
    api_data <- myProfile$get_api_data(url_new) %>%
      extract2("summaryData")
  } else if (api_type == "alerts/regionSyndromeAlerts") {
    api_data <- myProfile$get_api_data(url_new) %>%
      extract2("regionSyndromeAlerts")
  } else if (api_type == "alerts/hospitalSyndromeAlerts") {
    api_data <- myProfile$get_api_data(url_new) %>%
      extract2("hospitalSyndromeAlerts")
  } else {
    writeLines("Error: API did not work as expected. Please check your URL, dates, and password before trying again.")
  }

}

Dear @sara-chronister,
An implementation of the function you suggested has been pushed to the dev branch. Please, check it here. Also, feel free to install the version of the package in the dev branch (devtools::install_github("cdcgov/Rnssp@dev")) in order to test the get_essence_data() function you suggested. Depending on the feedback, further improvements and/or testing, we shall determine whether it is worth including this function to the next release of the package.
Thank you for your contribution!


TypeError: subtables[i] is not a function at table.getKerningValue

TypeError: subtables[i] is not a function
    at table.getKerningValue (VM218 opentype.js:5536)
    at Font.getKerningValue (VM218 opentype.js:914)
    at fetch.then.then.then.font (VM491:60)

https://jsfiddle.net/crl/2o3sfhrg/1/
This error happens for Ek Mukta, Cardo, Cousine, Bungee Inline, Jomhuria,  Aref Ruqaa, NTR, Gurajada, Buenard fonts too

Hi,
thanks for the report. It happens with Raleway too. I will fix this soon.


Replace HorizontalExecution Mask by MaskStmt in OIR

Description
Replaces the mask in the horizontal execution in the OIR by mask-statements. This allows for merging several horizontal executions with masks which was previously impossible and proved to be an optimization bottleneck.
Requirements
Before submitting this PR, please make sure:

[x] The code builds cleanly without new errors or warnings
[x] The code passes all the existing tests
[x] If this PR adds a new feature, new tests have been added to test these
new features
[x] All relevant documentation has been updated or added

Additionally, if this PR contains code authored by new contributors:

[x] All the authors are covered by a valid contributor assignment agreement,
signed by the employer if needed, provided to ETH Zurich
[x] The names of all the new contributors have been added to an updated
version of the AUTHORS.rst file included in the PR

bors try


Add cutout support

Platforms affected
Android
Motivation and Context

Adds support for devices with cutouts or "notches".
Description

Uses getDisplayCutout() to reserve top/bottom space for it.
Testing

Tested on Samsung Galaxy S10 (with cutout), S8 (same resolution, no cutout), J3 (entry-level phone, older Android SDK), and Tab S (old tablet, just in case).

Thanks you're awesome!


Debug Adapter - Ship two versions of PTVSD with extension

Pip install old version of PTVSD on CI (can hardcode temporarily, as this will go away)
Note: Extension will only ship wheels for new version of ptvsd
The version for the new version of PTVSD will defined in requirements.txt
ptvsd_launcher.py would have been updated in #7001 to define the location of this old version of PTVSD

validated


Wrong variable name

In the line below, lookahead_time_ should be lookahead_dist_.
https://github.com/JohnTGZ/regulated_pure_pursuit_controller/blob/2204efd544e951d3464c218d552fb62e2d66f62e/src/regulated_pure_pursuit_controller.cpp#L137

Thanks for spotting this mistake! :) I have since comitted the fix to it on master.


Generate array of known instances

Describe the feature
When specifying multiple known instances of a value object, the source generator should generate a public readonly T[] KnownInstances field that contains all known instances.
This is great for scenarios where the value object is almost being used like an enumeration type and only known instances are used/allowed.

Hi, I started a very similar project but is focused more on enumerations . https://github.com/SteveDunn/Intellenum
Very keen on feedback, so please let me know what you think.

Hi @erri120 - does Intellenum suit your requirements? Your feature fits better with an enum focused library rather than a value-object focused library.
I'll close this for now, but if you think there's compelling reasons to have this, then please let me know.

Intellenum works perfect for this.


Feature request: more general support for external auto-completion

Right now plugin's vim.ui.input defines its own completion. It seems to conflict with other external (auto-)completion functionality. This is vaguely confirmed by hard-coded 'nvim-cmp' disabling. I understand that 'nvim-cmp' is the completion engine right now, but it would be nice to at least have notice somewhere that external completion engine should be disabled in specified buffer. For example, this caused a hard-to-find behavior in 'mini.completion' (echasnovski/mini.nvim#68).

Happy to disable mini completion by default, but there should be nothing wrong with having it enabled. I disabled cmp completion because it's usually undesirable in the input buffer, not because it was causing errors. I believe the issues that were reported are coming from some interaction between mini completion and "stopinsert". I can reproduce the issue with the following code:
require("mini.completion").setup()
vim.defer_fn(function()
  vim.api.nvim_feedkeys("Gohelloworld", "t", true)
end, 100)
vim.defer_fn(function()
  vim.cmd([[stopinsert]])
end, 1000)
vim.defer_fn(function()
  -- Now any attempt to insert triggers the error
  vim.api.nvim_feedkeys("i", "t", true)
end, 1500)

Thanks for automated disabling. I've added the note in 'mini.completion' docs, so that is not that necessary, but still nice.
Your example left me really puzzled, though. Not really a 'mini.completion' issue, but issue with InsertCharPre autocommand. I think I managed to narrow it down to some sort of weird behavior of Neovim itself. For example, that code works fine if vim.cmd([[stopinsert]]) is replaced with vim.api.nvim_feedkeys(vim.api.nvim_replace_termcodes('<Esc>', true, true, true), "t", true). Which is weird because :h stopinsert quite literally says "Works like typing <Esc> in Insert mode".
I'll ponder a bit until submitting an issue and probably close this after. Does this sound good?

Works for me. I wouldn't be surprised if it were some edge case within Neovim itself; I've noticed some odd behavior for startinsert in the past.

So from neovim/neovim#18395 it does indeed seem like a Neovim issue. Thanks for the code example! Closing as irrelevant to the plugin itself.


customer record not sync with stripe customers

Bug report

Extension name: [e.g. firestore-stripe-subscriptions]

Describe the bug
When the user logins, I create a document in the customer collection in firestore, document is the uid of the user and i add an email field, but i do not see a record added to stripe.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
i execute the following code in my react app,
this.dbStore                 .collection('customers')                 .doc(authUser.uid)                 .set({ email: authUser.email })                 .then((res) => {                   alert('created');                 })
Expected behavior
I confirm that the document is created.
But i do not see it on stripe.
Btw, the products that i add on stripe do get sync to my firestore collection.
also i had to change security rules for now because it would not let me create the document otherwise.
Screenshots
System information
browser chrome,

OS: [e.g. macOS, Windows]
Browser (if applies) [e.g. Chrome, Safari]

Additional context
Add any other context about the problem here.

Read the source of and understood. Deleted my authenticated user and began working.

Read the source of and understood. Deleted my authenticated user and began working.

Glad you got it working. If you have more questions regarding your integration you can jump on our technical chat on IRC: https://webchat.freenode.net/#stripe

Glad you got it working. If you have more questions regarding your integration you can jump on our technical chat on IRC: https://webchat.freenode.net/#stripe


OData functions are not working

Hi,
I am trying to use the OData function in power automation and getting below error.
Error:
status":400,
message:"The query is not valid.
Filter query.
https://{MySP}.sharepoint.com/_api/web/lists/getbytitle('{MyListName}')/Items?$filter=day(Birthday) eq 20 and month(Birthday) eq 7
Please help me to figure it out.
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 916d6284-9149-5d95-48d8-40c60ba9f3c7
Version Independent ID: 9c41a103-56d6-c186-26aa-ccd098a61f7e
Content: Use OData query operations in SharePoint REST requests
Content Source: docs/sp-add-ins/use-odata-query-operations-in-sharepoint-rest-requests.md
Product: sharepoint
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

@ashokghoghari please, remove $ before filter.
It should work then.

Removing $ before filter ignore my filter query.

Is Birthday an actual property name on the objects returned in the Items collection?  If Birthday is the name of a column in the list I'm not sure if we support a syntax to let you filter on a specific field easily.

Related to #5481 which was closed due to no activity. There are more examples given in this issue of OData date functions not working as per the documentation.
The day(), month(), year(), hour(), minute(), second() functions are stated as supported in the docs, see
https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/use-odata-query-operations-in-sharepoint-rest-requests#odata-query-operators-supported-in-the-sharepoint-rest-service, but there are no examples given of how to use them correctly.

@garrytrinder - Are we able to look into this? - I've never seen them used either, but have a use-case where they would be 🔥 - but judging from the threads here, the docs are simply outdate/wrong, would be awesome with a clarification 😊

Giving this a bump, because it's still a problem.  I'm trying to use year() in PowerAutomate when filtering a SharePoint list and just get the "The query is not valid".
This issue is over four years old.  I think it's time something was actually done about it...

I've done some more digging on this while working on a library to help write OData queries for SharePoint, and I think I've found the source of the error
In the old /_vti_bin/listdata.svc/ListName endpoints you could use filters like $filter=month(columnName) eq 2 these however never appear to have been ported over to the modern list endpoints (_api/web), and at this point I'm doubtful we'll ever see that.
Would love an official confirmation on my theory tho


Unity3d

Hi,
Im a Game Developer and I think your db is perfect for Unity (http://unity3d.com/), but the problem with Unity is that it only implement .Net 2.0 (and some things up to 3.5)  because it uses a custom mono version, but I manage to perform some small changes to make it works under Unity without any functionality or performance reduction in you base version.
It would me awesome to implement these changes or others similar (Maybe a isNullOrWhiteSpace String extension).
I think with a little publicity on the Forums this DB can be used a lot by Unity Developers.
PS: Awesome Job, Im using LiteDB and I think its awesome!!!.
Ruben.

Hi @buronix, thanks for your PR. I saw your project but isnt still in v4? In LiteDB.csproj has v4.0
I think that LiteDB use more api from v4.0... But your idea is fine, I upgrade to v4 to use Async but never apply that.

Hi, Sorry, Unity is a plataform to develop Games, a lot of Famours Games are developed under Unity (http://unity3d.com/showcase/gallery), and tons of indie Games  also, http://www.indiedb.com/engines/unity/games, this is the reason for Ithink it will be awesome support Unity, But Im not from Unity, Im a Indie Game Developer, actually developing a game underUnity.
About the csproj, Im not using it, so I change nothing with that, I only imported the LiteDB folder and performed the changes to make it work under Unity, so Im not using a dll, (Maybe in the final release).

Hi @buronix, I change myself last version of LiteDB to works in 3.5 framework. But Shell and Test must run in v4 (because v.1.0.4 is compiled in v4 and shell use v.0.9 and v.1.0.4 to be compatible with old versions).

Thanks a Lot!!


Port remaining icon sets

There are some additional icon sets in the iron-icons repo.

av-icons
communication-icons
device-icons
editor-icons
hardware-icons
image-icons
maps-icons
social-icons
update-icons

resolved by https://github.com/dart-lang/polymer_elements/commit/78377ec059daebc6a61db1ca9196f6fec3cb2aea


Remove newly added explicit version dependencies in gdal and netcdf.

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] If you are adding/removing a .spec file that has multiple-versions supported, please add @microsoft/cbl-mariner-multi-package-reviewers team as reviewer (Eg. golang has 2 versions 1.18, 1.21+)
[x] Ready to merge

Summary

Remove the explicit version in build/runtime dependency on hdf5 to unblock  the arm64 build.
Change Log

Remove newly added explicit version dependencies in gdal and netcdf

Does this affect the toolchain?

NO
Associated issues

Build break.

Links to CVEs

n/a

Test Methodology

Pipeline buddy build.

Previous PR checks succeeded. Latest commit only modified a changelog comment - skipping waiting for another build and merging.


Heisenbug: periodic error TextMarshaler error

On creating a Netlify site with no settings site (params are empty), I'm periodically getting this:
netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface

Sorry, it is in Go => string format.
This is in a loop of creating/deleting a site with no params. Seems to be about 1 in 10 chance.

Getting this a lot more often tonight... usually when running all tests (which are now up in the dozens). And it seems to only be the latter tests.
Could this perhaps be some sort of rate limiting error that the Netlify API client is not reporting properly? Terraform can make an awful lot of API calls in a very short period of time and I just now realized that I didn't have to configure any backoff parameters so unsure if that's related or not. Just an idea.
Here is a snippet example:
=== RUN   TestProvider
--- PASS: TestProvider (0.00s)
=== RUN   TestProvider_impl
--- PASS: TestProvider_impl (0.00s)
=== RUN   TestAccDeployKey_basic
--- PASS: TestAccDeployKey_basic (3.99s)
=== RUN   TestAccDeployKey_disappears
--- PASS: TestAccDeployKey_disappears (2.36s)
=== RUN   TestAccHook
--- FAIL: TestAccHook (0.71s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
=== RUN   TestAccHook_disappears
--- FAIL: TestAccHook_disappears (0.62s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
=== RUN   TestAccHook_updateData
--- FAIL: TestAccHook_updateData (0.60s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
=== RUN   TestAccSite_basic
--- FAIL: TestAccSite_basic (0.55s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
=== RUN   TestAccSite_disappears
--- FAIL: TestAccSite_disappears (0.49s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
=== RUN   TestAccSite_updateName
--- FAIL: TestAccSite_updateName (0.49s)
	testing.go:513: Step 0 error: Error applying: 1 error(s) occurred:

		* netlify_site.test: 1 error(s) occurred:

		* netlify_site.test: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface

It's possible that this is a rate limiting error, I'm going to dive into the logs. Can you try enabling debug mode? Setting os.Setenv("DEBUG", "1") should make open-api to log all the request/response interactions raw, which might let you see the response object.

@calavera Confirmed! 😊
HTTP/2.0 429 Too Many Requests
Content-Length: 70
Age: 0
Content-Type: text/plain; charset=utf-8
Date: Wed, 20 Dec 2017 17:22:52 GMT
Server: Netlify
X-Ratelimit-Limit: 3
X-Ratelimit-Remaining: -2
X-Ratelimit-Reset: 2017-12-20 17:23:52 UTC

{"code":429,"error":"API Deploy rate limit surpassed for application"}

Many API clients we work with in Terraform implement handling of the X-Ratelimit-* headers themselves (with options for backoff and so on). Is that something you're interested in? In the mean time we can probably do something...
In any case one issue is that that error isn't being parsed properly into an error message!

I asked our TF providers team and they said that the API client pretty much always handles this in some way. They gave me a couple examples to share if you're interested.
Azure: Azure actually does a really fantastic job. Retries are pretty much invisible and just work. They use go-autorest under the hood and here is the relevant code: https://github.com/Azure/go-autorest/blob/809ed2ef5c4c9a60c3c2f3aa9cc11f3a7c2ce59d/autorest/sender.go#L208 The only tunable they expose is "MaxRetries" and we just use the default.
AWS: The AWS client uses a Handlers struct which is a callback for various stages of the API request. One of those callbacks is Retry. But by default the AWS client handles the rate limit, waits the necessary window, and retries the request: https://github.com/terraform-providers/terraform-provider-aws/blob/cba83a50b79c55183b918152cd94aed1eaac8c98/vendor/github.com/aws/aws-sdk-go/aws/request/handlers.go#L10 And setting the handlers: https://github.com/terraform-providers/terraform-provider-aws/blob/cba83a50b79c55183b918152cd94aed1eaac8c98/aws/config.go#L437

Thanks for the info, those examples are super useful. I agree that we should handle the retries in the client.

This started happening again in some circumstances around timed out uploadFile call.  Re-opening to track and investigate.

Here's an example in the wild: https://app.netlify.com/sites/devopsdays-web/deploys/5c7dbf8c591fc60008c4fd86
We have almost nothing happening in our deploy that should take much time. Last week we had timeouts, and this started happening today. Happy to work with you if you want to try to reproduce/test with us.
/cc @mattstratton

Thank you @bridgetkromhout! We've identified the underlying issue and are working on a fix.  Once that's out, I'll dig around and figure out why errors aren't propagating correctly (to figure out what's causing the awkward TextMarshaler error to be what you are seeing, instead of something actually useful).

The offending parameter in the response seems to be application/json missing from Content-Type.  So its super important our endpoints set that header.  It seems like this is sometimes not the case, especially when things are going wrong.
Asking about the TextConsumer error in go-swagger's slack I received this tip:
it should only do that if there is no default content type set
at the global level in the spec

Which we do set if my understanding is correct.  This could be an error in the open-api runtime, or we aren't setting a definition correctly in our spec, however I suspect its a bug or some error handling in need of improvement.

Tips to fix upstream:

ic I just checked our templates
yeah we don't implement the text marshaller
it's probably very similar to the binary stuff though
https://github.com/go-swagger/go-swagger/blob/master/generator/templates/schema.gotmpl#L215-L233

The problem seems to be in this generated code:
// Code generated by go-swagger; DO NOT EDIT.

package sales_order

// This file was generated by the swagger tool.
// Editing this file might prove futile when you re-run the swagger generate command

import (
	"fmt"
	"io"

	"github.com/go-openapi/runtime"

	strfmt "github.com/go-openapi/strfmt"
)

// SalesOrderPostReader is a Reader for the SalesOrderPost structure.
type SalesOrderPostReader struct {
	formats strfmt.Registry
}

// ReadResponse reads a server response into the received o.
func (o *SalesOrderPostReader) ReadResponse(response runtime.ClientResponse, consumer runtime.Consumer) (interface{}, error) {
	switch response.Code() {

	case 201:
		result := NewSalesOrderPostCreated()
		if err := result.readResponse(response, consumer, o.formats); err != nil { /* It's failing in the call to readResponse. I presume because the response.Body() is nil *shrug* */
			return nil, err
		}

		return result, nil

	default:
		return nil, runtime.NewAPIError("unknown error", response, response.Code())
	}
}

// NewSalesOrderPostCreated creates a SalesOrderPostCreated with default headers values
func NewSalesOrderPostCreated() *SalesOrderPostCreated {
	return &SalesOrderPostCreated{}
}

/*SalesOrderPostCreated handles this case with default header values.

Created
*/
type SalesOrderPostCreated struct {
	Payload interface{}
}

func (o *SalesOrderPostCreated) Error() string {
	return fmt.Sprintf("[POST /controller/api/v1/salesorder][%d] salesOrderPostCreated  %+v", 201, o.Payload)
}

func (o *SalesOrderPostCreated) readResponse(response runtime.ClientResponse, consumer runtime.Consumer, formats strfmt.Registry) error {

	// response payload
	if err := consumer.Consume(response.Body(), &o.Payload); err != nil && err != io.EOF {
		return err
	}

	return nil
}

It seems to be failing in the call to ReadResponse in the 201 case. I'm still investigating, but perhaps the response.Body is nil and so it's failing to deserialize it?

As far as I am aware, its when we don't receive a content type of json, and it appeared to be an upstream generator issue.  I intended to look into it, but ran out of time in the window I had.

I believe I might have fixed this issue. See my issue here: https://github.com/go-swagger/go-swagger/issues/1917

@jeffreydwalter wow amazing.  I'll pull it in.

@bcomnes let me know how it goes. Should be enough to just update the openapi/runtime package.

@jeffreydwalter I don't think it does quite solve the issue, but I'll take the updates!  The issue I think we are running into here is twofold:

If the API you are talking to respondes in a weird way, say, returns a non json content type, you get a NoConsumer error.  While this is the cause of the error, it would be better if the client returned a better error along the lines of, Bad response, error code etc.
If the API should return JSON and it isn't, the API should be fixed to return JSON.

@bcomnes sorry for the false hope. 🙃 In my case I was dealing with issue number two. I had a third party API that was returning an empty body and text/plain in response to a 302 after a POST. The spec only had application/json specified for the content-type. Since the body was empty, the client was trying to unmarshal it as plain text and failing.

It seem to me that the TextConsumer is trying to unmarshal an empty body into models.Error and failing. Thinking about it further, I think my fix is inadequate. What happened when you updated openapi/runtime?

I think ultimately, that message is due to the fact that the API is returning a content type that the spec doesn't define. The spec and/or the API need fixing.
You can see in this comment that the content type is text/plain: https://github.com/netlify/open-api/issues/58#issuecomment-353127943
The openapi/runtime code is trying to cast the request data data.(encoding.TextUnmarshaler) and failing since models.Error doesn't implement the TextUnmarshaler interface. See: https://github.com/go-openapi/runtime/blob/3d6572c5a80826d5e7f6362d4c681875207c3ef6/text.go#L48

Its been a while, but iirc the ideas I had were:

Support encoding.TextUnmarshaler in the Error template.
Wrap the no-consumer error to return a better top-level error.  While no consumer IS the underlying problem, the consumer of the client should get an error that more closely resembles a server error or bad response error (e.g. what was the route, what was the code, what was the content type etc).

sorry for the false hope

No problem at all.  I appreciate the pings on possibly helpful updates and it sounds like you DID fix something that maybe affects us but I haven't realized yet.

Can someone unassigned me on this?  I can't for some reason.

Error: Deploy did not succeed: Failed to execute deploy: &{0 } (*models.Error) is not supported by the TextConsumer, can be resolved by supporting TextUnmarshaler interface
Seeing error like this when I tried to deploy just now


Make default cache global to any new client/service created.

Before the default cache is one per new client/service object, which is not nice if an app creates multiple objects because they will have individual caches instead of sharing.
So make the default cache global. If someone wants to have a cache with a different default expiration time, that will create another global cache.

[ ] @johnny-lai

lgtm

[lockit v4.9.2] merged via Lockit CLI on 2020-01-07 16:11:57.175051 -0800 PST m=+5.680590004


[SC] Fix wallet history duplicates

Closes VSTS #3995.

@codingupastorm tested it with the wallet and looks good. Wallet will need minor modifications to support the additional fields which I will PR there after this is merged.

Looks good to me!
Will redo that Ubuntu CI