non-optional optional argument "lat" for xc.indices.cool_night_index(tasmin: )

Setup Information

Xclim version:   0.37.0
Python version:  3.9.12
Operating System:  ubuntu linux 20.04.5, 5.14.0-1051-oem, x86_64

Description
The input array "lat" is considered optional in the documentation, yet if that input array is not given then xc.indices.cool_night_index drops an error:
TypeError: cool_night_index() missing 1 required positional argument: 'lat'
Also the source code does not indicate that lat should be considered optional as there is no fallback setting that becomes active if lat is not given.
This may be either a problem of the implementation or of the documentation.
Steps To Reproduce
No response
Additional context
Making the input of lat optional via changing
tasmin: xarray.DataArray, lat: xarray.DataArray, freq: str = "YS"
to
tasmin: xarray.DataArray, lat: xarray.DataArray | None = None, freq: str = "YS"
should be programmatically straightforward I believe, but I do not know whether that is scientifically sensible in this case.
Contribution

[X] I would be willing/able to open a Pull Request to address this bug.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Woups indeed! The way the indice is currently coded means lat is not optional and the doc should reflect that.
However, in other recent indices, we have added cf_xarray as a dependency to xclim. Using this, we could at least try to guess which coordinate of tasmin is the latitude when lat is not explicitly given.

Hi @christian-stepanek, you're right that the docstring is misleading.
As the indice is currently coded, lat is non-optional. Given that lat is only used as a switch to determine the month to examine in the tasmin time series, We could potentially support a default string variable (e.g. "north", "south") so that users can arbitrarily set a lat for their data. This would be useful gridpoint arrays without latitude, but that's a very specific use case.
I like @aulemahal's suggestion to use cf_xarray though. This should be quick to address. A fix will be available soon.

Thanks a lot to @Zeitsperre and @aulemahal for your quick response. And to all developers for providing a great toolbox to the community!!!
This here seems to work without any obvious problem:
import xarray as xr
import xclim as xc
import numpy as np
df_tasmin = xr.open_dataset(t2min.nc').data_vars["t2min"]
cool_night_index=xc.indices.cool_night_index(tasmin=df_tasmin,lat=df_tasmin.lat)

Then one could just use as a fallback the latitudes that come with the dataset, am I right? At least to me it also feels natural to use the latitudes for which the data is given.

Indeed! This is the essence of what I am suggesting. However, we don't want to assume that the coordinate is named "lat", because even though it is very common, it is not prescribed by any standards xclim follows. Which is why we would use cf_xarray, because we already follow the CF conventions in many places.
It would then look like:
import xarray as xr
import cf_xarray
import xclim as xc

ds = xr.open_dataset('t2min.nc')
cool_night_index = xc.indices.cool_night_index(ds.tasmin, lat=ds.tasmin.cf['latitude'])

Assuming that dataset has set a minimum number of attributes to it's latitude coordinate, allowing cf_xarray to detect it.


Don't Select/mark as read articles when navigating the app.

When using the option to mark as read when selecting articles there are a couple of usability issues:

When the extension is opened by default the "All feeds" section is selected, which marks the newest unread article as read invariably.
When trying to open a folder to read the articles of a specific feed, 2 clicks are needed. The first one selects the folder, and marks as read the newest article of this folder (something the usually probably does not intend to do). The second click opens the folder, so a single website can be selected.

just pushed update implementing this optionally to AMO


fix Unittest in do-not-added-attributes-directly

The commit https://github.com/cross-solution/YAWIK/commit/4d4ada8459f46bc4c775e6691bf581a625196bcf triggers an E_USER_DEPRECATED warning, if properties are accessed directly, In addition a couple views, controllers etc. are changed.
https://github.com/cross-solution/YAWIK/blob/b30b39326746d0b74f0f1e7f62453754adc2b699/module/Core/src/Core/Entity/AbstractEntity.php#L40
Tests are failing now. Please fix them

@kilip I've marked the following test at skip. But they should be fixed.
Can you do this?
cbleek@xenon:~/Projects/YAWIK$ grep -r YAWIK/issue module/*/test
module/Core/test/CoreTest/Entity/AbstactEntityTest.php:        $this->markTestSkipped('must be revisited. https://github.com/cross-solution/YAWIK/issues/348');
module/Core/test/CoreTest/Entity/AbstactEntityTest.php:        $this->markTestSkipped('must be revisited. https://github.com/cross-solution/YAWIK/issues/348');
module/Organizations/test/OrganizationsTest/Entity/OrganizationReferenceTest.php:        $this->markTestSkipped('must be revisited. https://github.com/cross-solution/YAWIK/issues/348 ');

@kilip I've merged the branch into the develop. The Tests are still marked to skip and have to be fixed

Perfekt. Thank you


Use the correct index variable to access the trees array

Currently the i variable is used to access the trees array instead of the j variable which fails in cases where the number of trees is inferior to the number of data points that predict is run on.

thanks!


Fix missing ihipLogStatus

@pzins I have fixed this in #400. Ideally we should not call hip API from a hip API.

Thanks for submitting this change. However abandoning this since this change was included in a different patch that was fixing this in a cleaner way.


Fatalities in the Israeli Palestinian War Analysis

ML-Crate Repository (Proposing new issue)
:red_circle: Project Title : Fatalities in the Israeli Palestinian War Analysis
:red_circle: Aim : The aim of this project is to create an analysis model for analyzing the fatalities caused due to the war situation.
:red_circle: Dataset : https://www.kaggle.com/datasets/willianoliveiragibin/fatalities-in-the-israeli-palestinian
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Participant ID (If not, then put NA) :
Approach for this Project :
What is your participant role? (Mention the Open Source Program name. Eg. HRSoC, GSSoC, GSOC etc.)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Nice approach. Issue assigned to you. Start working on it.
@gourav-pramanik

Hi @gourav-pramanik any update on this issue?

Hi @abhisheks008 I am working on it, I will be creating a PR by this week.


Update php.sh

Description
Install additional phpunit according to PHP version

Related issue:
Check list

[ ] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

Hi @Tarasovych,
unfortunately, we cannot accept this contribution due to the following reasons:

having a lot of if statements requires manual maintenance, which we are trying to avoid, because there are plenty of software on the images, and we cannot afford manual maintenance unless it cannot be avoided.
multiple PHPUnit version consumes space, and we are concerned about it for Ubuntu images as we had some incidents due to free space
Multiple versions installed side-by-side may bring conflicts, and we don't have expertise to solve them.

Official recommendation is to use actions whenever possible as a more reliable and flexible way of using images. So I am still advocating for using special action as it was suggested here https://github.com/actions/virtual-environments/pull/3778#issuecomment-884848817.
I am closing this PR, please, feel free to contact us in case of any other questions. Thanks.


Incorrect URL for market chart range

Currently it is using coins/$id/market_chart which results in an error because parameters are missing.
This should be coins/$id/market_chart/range

Thanks!


Documentation error in Go code

In Go section, there seems to be multiple errors

This code example azopenai.NewKeyCredential(azureOpenAIKey) might be wrong I guess as Go cannot find "NewKeyCredential". Shouldn't it be azcore.NewKeyCredential(azureOpenAIKey)
Cannot recognize Deployment:  modelDeploymentID
Trmming my AZURE_OPENAPI_ENDPOINT url "?api-version=2023-09-15-preview" which given "resource not found error"

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

ID: 4833a089-660d-364f-82a4-1fc26522b6ec
Version Independent ID: 2c415b16-f888-a44b-64d7-a9d1732dacb6
Content: Quickstart - Get started using GPT-35-Turbo and GPT-4 with Azure OpenAI Service - Azure OpenAI Service
Content Source: articles/ai-services/openai/chatgpt-quickstart.md
Service: azure-ai-openai
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@wallgeek
Thanks for your feedback! We will investigate and update as appropriate.

@wallgeek
Thank you for bringing this to our attention.
I've delegated this to content author, who will review it and offer their insightful opinions.

Thanks for the feedback. The update to the docs to address this issue have been merged internally and will go-live in the public docs tomorrow.

#please-close


check the status of requests to the pdf merger

the pdf merger went down unexpectedly, but the logs on the councilmatic side did not indicate anything had gone wrong. there is an opportunity to verify that post requests return a 200 status code in the compile_pdfs command. consider using that opportunity to raise exceptions, so we know something isn't working.

Could we also have logs further upstream? BGA has a pattern for nginx logging – could we do something similar with supervisor?

As of 5:10pm PST 11/30, the packet for this Agenda was available: https://boardagendas.metro.net/event/regular-board-meeting-52018b89a7ba/
However, today the packet link is missing.
Only one change on our side in the meantime ... shortly after 5:10pm 11/30, Omar had to export and re-publish the Agenda. Not sure whether this would have an impact, just wanted to give you all the info we have! Can you please look into getting the packet back up?

@shrayshray - the packet is visible now. I was doing some testing with the metro-PDF-merger, which likely caused the delay.

@reginafcompton phew, thank you!!


From private repo

@SyntaxC4 : Thanks for your contribution! The author, @aczechowski, has been notified to review your proposed change.


Add comoving volume element calculation to the background module

An essential quantity to calculate is the comoving volume element, dV/dOmega dz, or the comoving volume per unit redshift and solid angle. This can be accomplished by combining splines already present in CCL. For reference, see eq. 28 of this paper by David Hogg.
The equation to be implemented is

This issue is very easy, and could serve as a good hack day project at CMU.

@tmcclintock I'm guessing you'd still like to see this?

Hi @nikfilippas ,
if you want, feel free to use the code for the coming volume that was coded by me, Marco Bonici and Matthijs van der Wild.
I also have a similar code in my own pipeline (a DESC Project).
Here is the link to the coming volume function in our code for CosmOracle https://github.com/nikosarcevic/CosmOracle/blob/main/background.py
Let me know if you need help with implementing it.

Hey Niko! I have already implemented it in a Python-only version of CCL which I'll submit for review in a few weeks (hopefully), after some of the other stuff gets pushed to the main branch. It is here, but for now it only lives in my own repo. It isn't a much requested feature and that's why I have refrained from opening a separate PR just for this, so that the PR list isn't cluttered.
Having a quick look I think our implementations are equivalent, right?

I see! the only thing I would point out which is important is the omega_k part -- there is a good discussion around omega_k and David Hogg got good comments about it from Phillip Helbig back in the day. so we included that special case so have a look at our code, https://github.com/nikosarcevic/CosmOracle/blob/7dfdc63a127b7282dbbfa19db7b97789a611faca/background.py#L136

Brief follow-up after discussion in private: CCL defines Cosmology objects given Ω_k, and then calculates Ω_Λ, while CosmOracle calculates Ω_k from a given Ω_Λ. Which essentially means that CCL doesn't suffer from this truncation problem.


Add scale effect on hover of project cards

Assign this to me! 😄

@tymnec please start working on it.

@tymnec I think hover:scale-100 hover:duration-300 would be fine

But Now I have added hover:scale-110 and duration-700. Actually that was smooth 😄

Should I change it?

Should I change it?

I have verified that and its perfect.
Keep it up mate. Great job !


Named method arguments

Assume the following code:
def fn(arg_a, arg_b, arg_c)
  ...
end

fn(1, 2, 3)
fn(1, 2, arg_a: 3)
fn(arg_a: 1, arg_b: 2, arg_c: 3)
fn(arg_c: 1, arg_b: 2, arg_a: 3)

JavaScript has no concept of named arguments. An object argument would of course be possible, but that would leave out the first and second variant. I don't want to litter the function definitions with too much new code, but I'm not sure there are any other options.

Setting milestone to 1.1.0 as this is out of scope when running Crystal in isolation.


Bottleneck 1.2.0 compiling error on Ubuntu 14.04 inside a Windows 7 VMware

Hi,
Since 1.2.0 I have this error when trying to install Bottleneck using pip (1.1.0 pip install worked fine):
    bottleneck/src/move_median/move_median.c: In function ‘mm_get_median’:
    bottleneck/src/move_median/move_median.c:522: error: ‘NAN’ undeclared (first use in this function)
    bottleneck/src/move_median/move_median.c:522: error: (Each undeclared identifier is reported only once
    bottleneck/src/move_median/move_median.c:522: error: for each function it appears in.)
    error: command 'gcc' failed with exit status 1
Command "xxxx/Python-2.7.12_install/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-_7Pumy/Bottleneck/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-C9J0Vy-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-_7Pumy/Bottleneck/

Thanks for the report.
Does the error occur when you install without pip? What OS are you using?

Sorry I did not test without pip, I will try it.
My OS: Ubuntu 14.04.5 LTS x86_64 inside a Windows 7 VMware

Installing with pip works for me on unbuntu 14.04. Could you try installing the issue_157 branch with pip?

I had one unit test failure on my first commit to the issue_157 branch. I made a second commit. All tests pass. Could you give it a try?

Thanks a lot this fixes my problem!
Note that I get these warnings:
    In file included from bottleneck/src/move_median/move_median.c:10:
    bottleneck/src/move_median/move_median.h:88: warning: function declaration isn’t a prototype
    bottleneck/src/move_median/move_median.h: In function ‘MM_NAN’:
    bottleneck/src/move_median/move_median.h:90: warning: implicit declaration of function ‘memset’
    bottleneck/src/move_median/move_median.h:90: warning: incompatible implicit declaration of built-in function ‘memset’

Hmm...do the unit tests pass?
import bottleneck as bn
bn.test()

Yes they pass
>>> import bottleneck as bn
>>> bn.test()
Running unit tests for bottleneck
NumPy version 1.11.2
NumPy relaxed strides checking option: False
NumPy is installed in xxxx/Python-2.7.12_install/lib/python2.7/site-packages/numpy
Python version 2.7.12 (default, Oct 25 2016, 12:28:39) [GCC 4.3.2]
nose version 1.3.7
.........................................................................................................................................................................
----------------------------------------------------------------------
Ran 169 tests in 69.586s

OK
<nose.result.TextTestResult run=169 errors=0 failures=0>

Thank you for reporting the warnings. I'd like to fix them. I made another commit to the issue_157 branch. Could you see if it silenced the warnings? (I don't see them so I can't tell).

It worked, warnings fixed.
I also had this warning:
bottleneck/src/reduce.c:2786: warning: ‘axis’ may be used uninitialized in this function

I should see that warning too. Weird that I don't. A made another commit that should get rid of the warning. And I tweaked the previous commit. Hope it works.


Image stage is not centered

Create a chat based on Model: Stable Diffusion XL
Send a message
Note that "image" stage is not centered -> bug

Expected: Stages should be centered

Closing the ticket as buttons in chat history were re-designed. The issue is not valid now.


fix: don't load plugin if extension data is empty

I have the overseer extension enabled, and it was causing overseer to alway loading on startup, adding about 100ms to startup time even when there were no tasks set for the current session.
This prevents any plugin associated with the extension from loading if the data is empty.

I think I'd prefer to solve this from the other direction instead: making the overseer extension only save data if any tasks are present https://github.com/stevearc/overseer.nvim/commit/8a830905c10d929033aa0fefa318fb6d9e18f5b8
Side note, how are you getting that timing information? The only thing the extension should do with empty data is require("overseer") https://github.com/stevearc/overseer.nvim/blob/8a830905c10d929033aa0fefa318fb6d9e18f5b8/lua/resession/extensions/overseer.lua#L22
That won't even run the setup() function and it doesn't require any other modules, so the only work really is two requires: one for the extension file and one for overseer itself. I don't think it's possible for that to take 100ms, so either there's something wrong with the measurement or there's some mystery work happening that I missed.

Side note, how are you getting that timing information?

My bad, it seems overseer was loading nvim-dap, which contributed to the additional 100ms startup time. Maybe it would be a good idea to make the nvim-dap integration optional?

I've just exposed the method for patching nvim-dap https://github.com/stevearc/overseer.nvim/commit/c1ef281a078d2f815ec669f4b1af358d5624ccda
You can pass in dap = false to overseer.setup(), and then manually run require("overseer").patch_dap(true) later when nvim-dap is loaded.


fix(versions): update Activiti/activiti-cloud-full-chart-security versions

UpdateBot pushed helm dependency: activiti-cloud-full-example to: 7.1.208

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-full-example 7.1.208


feat: add group and preset table widget

merge after #164
This PR adds to the gui a table widget (_group_preset_table_widget.py) that contains the group and presets retrieved from the loaded system configuration.
I also added 3 new groups to test_config.cfg for tests (_combobox_no_preset_test, _lineedit_test, _slider_test).

here's a very minor annoyance with the dropdown. I'm not even really sure how to fix this, but I suspect it will bug you too and maybe you'll figure it out 😂

@tlambert03 I think I fixed this annoying issue with _set_combo_view 😂

I see you moved the tab order back :)  ... I'm gonna move it again.  I don't like having the snap tab and the MDA tab (both related to acquisition, just different n dims), separated by a config-like tab.  It's the least like the other tabs and I think it needs to be over on the right.  maybe later we place it elsewhere entirely?


Error importing with SPM

When importing PostHog via Swift Package Manager I end up with an error.
Could not build Objective-C module 'PostHog'

To reproduce the problem:
Simply create a new Xcode project using Swift and import PostHog from "https://github.com/PostHog/posthog-ios".
I'm not sure if I'm missing something basic or the package is not compatible with SPM. All ideas are appreciated!

More specifically, XCode complains with the following error:
'PHGMiddleware.h' file not found

Occurs in the file posthog-ios/PostHog/Classes/Payloads/PHGPayloadManager.h on line #2

I'm also experiencing this problem. Did you manage to find a solution to the issue?

@arunrdd did you find a way to solve this error?

+1 to the people experiencing this problem.

@mariusandra what is the status on this? We are still getting this error with importing objective-c headers

Version 1.4.0 should finally fix this!


Move googleapis.BUILD to googleapis/googleapis/**/BUILD

The source of truth for these files is inside Google, so we need to make the changes there.

Done https://github.com/googleapis/google-cloud-cpp/pull/3842


Guidance text boxes showing markup when in edit view

When editing existing guidance the text boxes require you to input the html markup rather than the displaying the usual wysiwyg editor. You are able to edit the text and as long as you use html it does work as expected.
For example:

probably related to the tinyMCE boxes

Looks good to me. @pherterich / @magdalenadrafiova do you want to confirm?

when it goes to the guidance list I can see for a split second the html code bu then it jumps to the text:


BottomSheet When cancelled, the back does not fade out

https://github.com/afollestad/material-dialogs/issues/1907


Adding check for export to csv

Issue #: https://github.com/bcgov/met-public/issues/
Description of changes:

Added a new role for export to csv.
Disabled export to csv for users not having this role

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #2062 (84230d6) into main (72da1e2) will increase coverage by 0.01%.
Report is 2 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2062      +/-   ##
==========================================
+ Coverage   69.29%   69.30%   +0.01%
==========================================
  Files         454      454
  Lines       14406    14411       +5
  Branches     1115     1115
==========================================
+ Hits         9983     9988       +5
  Misses       4232     4232
  Partials      191      191

Flag
Coverage Δ

metapi
78.10% <100.00%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

...nents/comments/admin/reviewListing/Submissions.tsx
84.61% <ø> (ø)

met-web/src/services/userService/constants.ts
100.00% <ø> (ø)

met-api/src/met_api/services/comment_service.py
80.18% <100.00%> (+0.77%)
:arrow_up:

met-api/src/met_api/utils/roles.py
100.00% <100.00%> (ø)


[Bug]: Login only allows Shopify Partners as option

Please confirm that you have:

[X] Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
[X] Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?
Extension
Expected behavior
Logging in via the CLI allows store admins who have Shopify+ and extensibility enabled to login directly to their store, not as a partner since they're working on and deploying to their own store directly.
Actual behavior
After successfully logging out, when the CLI attempts to facilitate the login flow, it only pushes you in to the Shopify Partners login flow, instead of allowing shop admins who have extensibility turned on to be able to login directly to their own store.

Verbose output
This would publish api keys.

Reproduction steps

After logging out run npm run dev
CLI automatically pushes you to partners auth flow rather than allowing you to choose the store.

Operating System
Mac, latest
Shopify CLI version (check your project's package.json if you're not sure)
3.57.1
Shell
zsh
Node version (run node -v if you're not sure)
20.9.0
What language and version are you using in your application?
Node

I'm afraid the CLI for apps currently requires a Shopify Partners account. But thanks for the feedback, we are aware of the issue and we are working to improve the experience.

@gonzaloriestra Why was this closed as 'completed' when it is still an issue? Our UI for our existing store prominently says we have the feature but you closed this issue as 'completed' even though we still can't use it?

Not sure how this is acceptable.

I closed it because it's not a bug, but a feature request and we are already aware. Thanks for the suggestion!

How is it not a bug when my UI shows we already have the feature but we
can't use it because the ability to is absent in the CLI?
On Fri, Mar 22, 2024 at 10:20 AM Gonzalo Riestra @.***>
wrote:

I closed it because it's not a bug, but a feature request and we are
already aware. Thanks for the suggestion!
—
Reply to this email directly, view it on GitHub
https://github.com/Shopify/cli/issues/3576#issuecomment-2015329371, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BCQCH22U2GWEVQUZR26V5BLYZRD3PAVCNFSM6AAAAABE4C3LV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGMZDSMZXGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Not sure who your product owner is for Shopify+, but the way you're
communicating all of this nuanced information to your end user is anything
but clear.
Having a little sub text on a page with thousands of words on it doesn't
make it clear what features do and do not require a partner account. More
importantly, there is absolutely no explanation as to why some are
reserved for partners, especially when again the UI clearly says we have
Checkout Extensibility turned on.... which to any reasonable person would
communicate that we have all of the features, not just a very limited
subset of the features.
Yet again I share this screenshot:
[image: image.png]
To me, any reasonable person would see this and think that means we have
access to the full suite of features and functions, including deploying
custom extensions via CLI.
If you're saying that's not true, then your product team needs to really
circle back and update who gets to see this message, and if they see a
message like this, it needs to be *abundantly *clear that you do not mean
we have all of it turned on.
Like it could say, '...pages are upgraded to Checkout Extensibility
(Basic)' - and then you could have very clear documentation in your docs
that makes it clear there is Extensibility 'Basic' and 'Advanced' and then
make it more clear on both pages that 'Basic' every one gets, and
'Advanced' only partners get, which I still think is a huge product miss
given you're targeting mid-level+ sized companies with Shopify+ who
typically have development resources, but at least then from the UI in the
admin it's abundantly clear from the get go that there is additional
functionality that I may not have access to.
On Fri, Mar 22, 2024 at 10:37 AM Gonzalo Riestra @.***>
wrote:

There are many features in Checkout Extensibility that don't require the
CLI.  As explained here:
https://shopify.dev/docs/apps/checkout/product-offers/post-purchase/getting-started#requirements
—
Reply to this email directly, view it on GitHub
https://github.com/Shopify/cli/issues/3576#issuecomment-2015360932, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/BCQCH22V3A4KCHLDBLWPOPDYZRF33AVCNFSM6AAAAABE4C3LV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGM3DAOJTGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

I'm sorry if the documentation is not clear enough, I'll share this feedback internally to improve it.

Additionally, to say there are "many features available" without CLI is a bit of an oversell. The fact that clicking 'add app block' has no basic blocks in there (like basic input fields) makes this editor mostly useless and requires a company to have access to CLI:

So yet again, your product interface is communicating both implicitly and explicitly that I should be able to do more with my own store with Extensibility than I am actually able to do.
This is a 'Bug' by omission. It is a bug by lack of empathy to the end user. I get that in startup world its "all hype all the time" but when you're rolling out an editor that doesn't actually let you 'extend' your checkout page without CLI access.... isn't your communication about extensibility being turned on just a lie?


[1.8.x] Make Keys.loggerContext and LoggerContext() public

Starting with sbt 1.8.0-RC1 a LoggerContext will set its internal closed status to true:
https://github.com/sbt/sbt/blob/f974cd3bab0b8d09d031414c0741035ceba221b2/internal/util-logging/src/main/scala/sbt/util/LoggerContext.scala#L184-L188
The line closed.set(true) was introduced in #6992.
Because this AtomicBoolean is true now, it of course is not possible to re use a LoggerContext anymore:
https://github.com/sbt/sbt/blob/ec770668c924432d017204610390b102fa5b7f3d/internal/util-logging/src/main/scala/sbt/util/LoggerContext.scala#L142-L149
So far so good, this seems correct.
However this is causing problems with the Play Framework, which now runs into that exception with sbt 1.8, see https://github.com/playframework/playframework/issues/11527
So basically Play has a special NonBlockingInteractionMode which causes an app to continue to run in the background when calling run in a sbt console. That means, when run is "finished", there is still a (server) thread running that can serve requests. We use that for scripted tests. It's actually the same mechanism that sbt's bgRun is using, only that NonBlockingInteractionMode was implemented long time before bgRun was introduced in sbt 1.0.
Until sbt 1.7.x this was working fine, even though the background thread was using a state's loggercontext that, in theory, was closed already, but wasn't marked as closed (even thought the close method ran).
To test things out, I also came up with a clean room bgRun implementation in Play, that resembled what the NonBlockingInteractionMode is doing and I was running in the exact same exception. That bgRun looked somehow like this:
// Not the full code, just for demonstration purposes
bgRun: Initialize[InputTask[JobHandle]] = Def.inputTask {
    val service = bgJobService.value
    service.runInBackground(resolvedScoped.value, state.value) { (logger, workingDir) =>
      // At some point later, triggered by the Play server when a request comes in and the app has code changes:
      Project.runTask(Compile / compile, state) // re-compile the project
    }
}.evaluated

The problem is that the body of runInBackground, which at some point may calls Project.runTask, is not running in the bgRun lifetime anymore, but in a background thread, so after the bgRun task finishes the loggercontext gets closed. Project.runTask(...) however tries to access the loggercontext of the passed state which of course is closed now.
I tried a lot to workaround that or to come up with another solution. However the only solution that I found and IMHO think is the only one to be able to resolve that (right now) is to "wrap" Project.runTask(...) calls with an open loggercontext, which needs to be attached to the state. To do that, I need to be able to

initialized a LoggerContext - but the apply method is private right now
attach that loggerContext to the state with state.put(Keys.loggerContext,..). - but Keys.loggerContext is private right now

Using this patch here I was able to make both, Play's NonBlockingInteractionMode and sbt's bgRun, work in Play.
These lines of https://github.com/playframework/playframework/pull/11441 create a loggercontext and closes it afterwards. I also finally was able to implement bgRun in Play in the last commit of that PR.
@eed3si9n If there is nothing that speaks against opening up this key and method I would be happy if you can merge this, I will provide PRs for the 1.9.x and develop branch afterwards.

One workaround might be moving PlayRun into sbt.play.run package, and define an alias in the play.sbt.run package object to compatibility.

Yeah, I was thinking about that. Howver, I am just wondering is there a reason to keep those things private?

Yeah, I was thinking about that. However, I am just wondering is there a reason to keep those things private?

private[sbt] and sbt.internal are our signal that the implementation is subject to change, and not covered by binary compatibility. The less we can expose the sbt internals out to the plugin ecosystem the better for general stability.

@eed3si9n Alright, I moved the object to the sbt package now, so let's close that PR for now.


Journal Club with QUE and qBraid

We will do an event on December 12th.
We can invite Womanium, QOSF, QUE, and Unitary Fund.  CQTech
Junyu Liu

Let's meet every Wednesday 6pm and discuss how to organize the event.

Yesterday we don'0t so the meeting :(  and I talk with PIQUE and they say
That would be great! Maybe we could have one journal presentation from each of the organizers on different weeks or different months too


Blur input field on enter/geocode

Fixes #4916.
This fix makes sure that the input box is unfocused after hitting enter to geocode. Previously this was not the case in Firefox.
@hpinkos can you review and merge?

Looks great @erikmaarten!  Thanks!
I'll update CHANGES.md in master


Fix DeltaTable forPath

In this PR, I added exception handling for forPath method in DeltaTable.scala.
After the change, Delta Table will make sure create instance just for "Delta Source", other sources will throw an exception.
This PR is tested by DeltaTableSuite.scala

LGTM. Merging this soon.


The information of validating guardrails and gleaning cannot be saved.[Web-UI]

As stated in the title, the validating information cannot be saved and executed correctly through the web-ui.

Thanks for flagging! I'll take a look later today

Hope it works now; please let me know!

LGTM, Thanks!👍👍👍


[External Request] "Config. Excel Exchange" - SetSelectedTables()

We would like to skip tables when importing config packages from Excel by calling "Config. Excel Exchange" - SetSelectedTables() beforehand.
Currently we are able to override which records are exported using "Config. XML Exchange" - OnBeforeApplyPackageFilter(), including being able to skip all records and just export a blank template. Being able to filter the specific rows/records from being imported is not required for this request.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 12340.


Decoding post message metadata

You'll notice there's an empty dispatch method, I had to add this so that so the Dispatcher protocol was being met and I could properly test this code. I kept it since that's what I'll work on next.

:shipit:


Why executeHttpRequest ignores forwardAuthToken for an NoAuthentication destination ?

This is a follow-up question to the issue: https://github.com/SAP/cloud-sdk-js/issues/3625
The following sequence will result in a registered destination (defaulting to NoAuthentication authentication type)
const cloudSdkConnectivity = require('@sap-cloud-sdk/connectivity');

const poster = {
          name: "POSTER-DESTINATION",
          url: "https://poster.mydomain.com",
          forwardAuthToken: true
        };

await cloudSdkConnectivity.registerDestination(poster, {jwt: retrieveJwt(req) });

with the following definition:
destination: {
  "name": "POSTER-DESTINATION",
  "url": "https://poster.mydomain.com",
  "forwardAuthToken": true,
  "authTokens": [
  {
    "value": "eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vYXRlYW0uYXV0aGVudGljYXRpb24uc2FwLmhhbmEub25kZW1hbmQuY29tL3Rva2V
dRtbGkUZGSO_vj1_YA",
    "expiresIn": "1678217546",
    "error": null,
    "http_header": {
      "key": "Authorization",
      "value": "Bearer eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vYXRlYW0uYXV0aGVudGljYXRpb24uc2FwLmhhbmEub25kZW1hbmQuY29tL3Rva2VudRtbGkUZGSO_vj1_YA"
    },
    "type": "Bearer"
  }]
}

This works as designed (cf https://github.com/SAP/cloud-sdk-js/issues/3625#issuecomment-1457976465)

With forwardAuthToken option, the token used to execute the request is sent to the destination, see here.

And eventually we can use the registered destination in a call to executeHttpRequest passing it either as a destination object:
const response = await httpClient.executeHttpRequest(
  {
    destination: destination,
    jwt: retrieveJwt(req)
  }
);

or as a destination name:
const response = await httpClient.executeHttpRequest(
  {
    destinationName: "POSTER-DESTINATION",
    jwt: retrieveJwt(req)
  }
);

However, a bit to my surprise, the executeHttpRequest just ignores the authTokens[0].http_header and the call returns 401.
After a bit of tinkering it looks to me the executeHttpRequest will just ignore destination payload headers if the AuthenticationType is or defaults to NoAuthentication.
This is a bit counter-intuitive, as one might expect the above method to simply pass through any headers in the authTokens[0].http_header;
and very much at odds with the behaviour of @sap/approuter.
I would even risk qualifying this a bug and asking executeHttpRequest to pass through any headers from destination payload (==  authTokens[0].http_header) regardless of the destination authentication type.
what do you reckon ?

Hi @ptesny ,
I reckon this behavior is by design. As such services don't require any authentication, the auth token from the destination are not added to the final request by the SDK, by default.
However, you can still pass it as custom header in the requestConfig in the executeHttpRequest function.
const config: HttpRequestConfig = {
        method: 'GET',
        headers: {
          authorization: <your token>
        }
      };
executeHttpRequest(destination, config);

Hi @deekshas8 , indeed that's the cloud sdk behaviour; and at odds with approuter's stance on it....
having said that how would you explain that I see the sdk is adding the auth token from the destination if....I add it ?
  const key = destination.authTokens[0].http_header.key;
  const value = destination.authTokens[0].http_header.value;
  const url = destination.url+req.query.path;

  var config : HttpRequestConfig = {
    method: 'get',
    url: url,
    timeout: 60*10000,
    headers: {}
  }
  HttpRequestConfig.headers[key] = value;

  console.log('POSTER: ', JSON.stringify(options, 0 , 2));

 const response = await httpClient.executeHttpRequest(destination, config);

POSTER: {
"method": "get",
"url": "https://poster.mydomain.com/?host=toto.com",
"timeout": 600000,
"headers": {
"Authorization": "Bearer eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vYXRlYW0uYXV0aGVudGljYXRpb24uc2FwLmhhbmEub25kZW1hbmQuY29tL3RcGpnpW6VpHXA"
}
}
[2023-03-08T09:42:20.062Z] DEBUG (env-destination-accessor): Attempting to retrieve destination from environment variable.
[2023-03-08T09:42:20.062Z] DEBUG (env-destination-accessor): No environment variable set.
[2023-03-08T09:42:20.063Z] INFO (register-destination): Successfully retrieved destination 'POSTER-DESTINATION' from registered destinations.
[2023-03-08T09:42:20.063Z] DEBUG (register-destination): Option 'forwardAuthToken' enabled on destination. Using the initial token for the destination.
[2023-03-08T09:42:20.063Z] DEBUG (proxy-util): Tried to read https_proxy or HTTPS_PROXY from the environment variables. Value is undefined.
[2023-03-08T09:42:20.063Z] DEBUG (proxy-util): Could not find proxy settings for https in the environment variables - no proxy used.
[2023-03-08T09:42:20.064Z] DEBUG (authorization-header): Getting authentication related headers for authentication type: NoAuthentication
[2023-03-08T09:42:20.065Z] DEBUG (authorization-header): Getting authentication related headers for authentication type: NoAuthentication
[2023-03-08T09:42:20.066Z] DEBUG (csrf-middleware): Method is GET no CSRF token needed.
[2023-03-08T09:42:20.066Z] DEBUG (http-client): Execute 'get' request with target: https://poster.mydomain.com/?host=toto.com.
The headers of the request are:
Authorization:<DATA NOT LOGGED TO PREVENT LEAKING SENSITIVE DATA>
authorization:<DATA NOT LOGGED TO PREVENT LEAKING SENSITIVE DATA>

Seeing the above:
The headers of the request are:
Authorization:<DATA NOT LOGGED TO PREVENT LEAKING SENSITIVE DATA>
authorization:<DATA NOT LOGGED TO PREVENT LEAKING SENSITIVE DATA>

makes me think that as I added my Authorization header the cloud sdk logic merged the headers from the destination payload anyway. Thus both Authorization and authorization carry the same auth token added twice....
If you confirm this is the case I'd rather call it a bug. what do you reckon?

Hey @ptesny,
your request configuration is merged with the configuration resulting from the destination. The destination has the authtoken, but it is not part of the resulting request configuration for this destination. This is due to the fact, that NoAuthentication is the used authentication type.
This behavior differs from how it is documented, so there is a problem either in the documentation or the implementation.
I believe it is the implementation, but we are currently checking the details on this, to be absolutely sure!

Thanks @marikaner ; The thingy is if I do not pass manually the headers from the destination payload the sdk will simply ignore the payload. But if I do it the destination payload will be merged with the manually passed destination payload.
that's inconsistent behaviour....
What would make it consistent is, regardless of the NoAuthentication type, any headers already present in the destination payload should be honored and passed along the business url call.
That would eliminate the inconsistent behaviour (which is a bug) and put the cloud-sdk on pair with the approuter behaviour....my 2 cents

Hey @ptesny, the auth token forwarding is indeed a bug and should happen no matter which authentication type was set. We will let you know once this is fixed.

@marikaner ; thanks for letting me know;

Hi @ptesny , we released v3.2.0 with the fix included.. Please test if this fixes the issue on your side.

@deekshas8 ; @marikaner ;
have you also tried to fix this one: https://github.com/SAP/cloud-sdk-js/issues/3634 ?


License

please provide license file. I love your plugin, but I can't use it on my work since there's no license

I don't know much about licensing, so what is the ideal license to use? I have no qualms with folks using this however they want as long as they aren't selling it as their own work!

https://help.github.com/articles/open-source-licensing/
i guess it should help. I think MIT license should fit

It's actually pretty easy to add this with github. You just create a new file on github.com with the name LICENSE and it brings up a dropdown!


Fix update-go-mods

Issue #, if available:
Description of changes:
Add missing semi colons to the newly added commands.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Add possibility to provide custom request parameters

This pull request is reaction to Issue #161 - How to set Header. It allows users to provide custom request headers (for authentication for example) and other parameters by providing their own URLSessionConfiguration, that is used for image data requests.

seems good. thank you for your cooperation 👍


Create non-side effecting equivalents for lodash functions

For proper functional programming, functions should not mutate in place. To overcome this when working with lodash I need to do something like
var c7 = _.set(_.assign({}, ab), 'b.c', 17)`

I plan on tackling this soon for assign, defaults, extend, I'll throw set on the list too. Feel free to add more that I should fix.

+1 this would be really big. This is one thing that has me on the edge with this and RamdaJS.
Thanks for all the hard work on lo-dash BTW! :beers:

Patched https://github.com/lodash/lodash-fp/commit/69fb8e1d11bdfefc19cb38c31f1dc6ac94ecd87b.


3.2.8 not uploaded to pip

Latest version installable by pip is 3.2.7. Thanks!

Uploaded 3.2.{7,8}, np <3


could dart create private constructor ?

such as Student can not be create by constructor, but can be a static method:
class Student {
  String? name;
  private Student(this.name);  // use _Student(this.name) also error

  static newInstance(String name) {
    return Student(name);
  }
}

then user use Student('sss') to create Student will be error, just can use newInstance

You just need to make the second part of a constructor name private, e.g.:
class Student {
  String? name;
  private Student._(this.name);  // This is a private constructor.
  ...
}

@Silentdoer, I'll close this issue because private constructors exist, and nothing in this issue indicates that they aren't working as intended. Please create a new issue if you do encounter something that doesn't work.

@Silentdoer, I'll close this issue because private constructors exist, and nothing in this issue indicates that they aren't working as intended. Please create a new issue if you do encounter something that doesn't work.

thank you


Add workaround for reconnection issue to documentation

Is your feature request related to a problem? Please describe.
It is a problem that client reconnection is not addressed
Describe the solution you'd like
This is just a workaround,  but here we go. It primarly uses flows and might be a
solution to be integrated with the library.

@Mr3zee if you see this not fit as an issue I am very sorry. but I thought it might help someone

Some utilities:
fun <T> Flow<T>.firstShareStateInBlocking(scope: CoroutineScope): StateFlow<T> {
    val started: SharingStarted = SharingStarted.Eagerly
    return shareIn(scope, started, replay = 1).let {
        it.stateIn(scope, started, runBlocking { it.first() })
    }
}

// this is helpful if using compose
fun <T : R, R> Flow<T>.collectAsStateIn(
    coroutineScope: CoroutineScope,
    initial: R,
): State<R> {
    val state = mutableStateOf(initial)
    onEach { state.value = it }.launchIn(coroutineScope)
    return state
}

Creating a client state that reacts to session changes and reconnection requests
@OptIn(ExperimentalCoroutinesApi::class)
fun createRPCClientState(
    options: RpcClientOptions,
    httpClient: HttpClient,
    dataStore: DataStore<Preferences>,
    reConnectRequestFlow: Flow<Unit>,
    coroutineScope: CoroutineScope,
): StateFlow<RPCClient> {
    return dataStore.data
        .map { it[PREF_RPC_SESSION] }
        .distinctUntilChanged()
        .flatMapLatest { newSession ->
            merge(
                flowOf(newSession),
                reConnectRequestFlow
                    .map { newSession },
            )
        }
        .mapLatest { newSession ->
            httpClient.rpc(options.baseurl) {
                newSession?.let { bearerAuth(it) }
            }
        }
        .runningReduce { oldClient, newClient ->
            oldClient.webSocketSession.close()
            newClient
        }
        .firstShareStateInBlocking(coroutineScope)
}

And to use the client (in compose, but can be used elsewhere):
val remoteServiceState = rpcClientState
        .map { it.withService<MyRemoteService>() }
        .firstShareStateInBlocking(viewModelScope) // <-- or other scope

@OptIn(ExperimentalCoroutinesApi::class)
val someFlowValue by remoteServiceState
    .flatMapLatest { it.someServiceFlow }
    .onEach { newFlowValue ->  /**/  } // optional - to peek the value when changed
    .collectAsStateIn(viewModelScope, initial = null)  // <-- or other scope

I am not that good in explaining, thus I just pasted the code hoping it could explain itself. sorry 😥


Tablet Asus me302c: crash of all apps after 1.9.4 version

Hi all,
As i wrote in the title, every version of this app after the 1.9.4 is affect of crash and bugs. I have android 4.3 here. The 1.9.5 version doesn't update the watched status and if I go to the film section the app crash. The latest version crash immediatly when I open the app.
The 1.9.4 works , but crash if I switch to the grid view of film section .
What can I do?

Unfortunately, I'm not doing any more bug fixes on the 1.9.x branches as all my development focus now is on the 2.0.0 support version.   Have you tried version 1.9.3 which should be available in the release section and you can download it and side load it on the system.
2.x will be focusing on Amazon Fire TV and Android TV devices, so may or may not work with Tablet and touch screens going forward.


Run CI builds for PRs/commits to c++14-compliant branch

Signed-off-by: The MathWorks, Inc<EMAIL_ADDRESS>

Codecov Report

Merging #723 (3a09583) into development (fa69c78) will decrease coverage by 1.20%.
The diff coverage is n/a.

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #723      +/-   ##
===============================================
- Coverage        89.78%   88.58%   -1.21%
===============================================
  Files              231       92     -139
  Lines            13806     6534    -7272
===============================================
- Hits             12396     5788    -6608
+ Misses            1410      746     -664

Impacted Files
Coverage Δ

framework/src/bundle/BundleRegistry.cpp
79.60% <0.00%> (-12.37%)
:arrow_down:

framework/src/service/ServiceEvent.cpp
71.79% <0.00%> (-5.76%)
:arrow_down:

...mework/src/service/ServiceReferenceBasePrivate.cpp
86.45% <0.00%> (-5.67%)
:arrow_down:

framework/src/service/ServiceRegistrationBase.cpp
77.66% <0.00%> (-4.39%)
:arrow_down:

framework/src/bundle/BundleResourceContainer.cpp
92.90% <0.00%> (-3.65%)
:arrow_down:

framework/src/bundle/BundleResourceBuffer.cpp
67.34% <0.00%> (-3.63%)
:arrow_down:

framework/src/service/ServiceListeners.cpp
96.40% <0.00%> (-3.60%)
:arrow_down:

framework/src/util/FrameworkEvent.cpp
61.81% <0.00%> (-3.46%)
:arrow_down:

framework/src/util/Properties.cpp
55.55% <0.00%> (-3.45%)
:arrow_down:

framework/src/util/Utils.cpp
75.58% <0.00%> (-3.32%)
:arrow_down:

... and 207 more


HDDS-2980. Delete replayed entry from OpenKeyTable during commit

What changes were proposed in this pull request?
During KeyCreate (and S3InitiateMultipartUpload), we do not check the OpenKeyTable if the key already exists. If it does exist and the transaction is replayed, we just override the key in OpenKeyTable. This is done to avoid extra DB reads.
During KeyCommit (or S3MultipartUploadCommit), if the key was already committed, then we do not replay the transaction. This would result in the OpenKeyTable entry to remain in the DB till it is garbage collected.
To avoid storing stale entries in OpenKeyTable, during commit replays, we should check the openKeyTable and delete the entry if it exists.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-2980
How was this patch tested?
Added unit test.

Integration test failure (timeout) is unrelated and passes locally. Re-triggering the checks.

Thanks for the review @bharatviswa504 .


Error when storing JSON data in SUPER column

Hi, does this package support Redshift's SUPER datatype?
I'm inserting a valid JSON data into SUPER column and getting following error:
java.sql.SQLException:
Error (code 1224) while loading data into Redshift: "Format with multiple values without array or object"
Table name: "PUBLIC"."telemetry_data"
Column name: telemetry
Column type: super(16384000)
Raw line: "{"created":"2024-03-16T18:22:56.258Z","deviceSerial":"5500TX-0000-0036","deviceId":"000799aa5b66","bundle":[{"category":"ExtTlsTelemetry","created":"2024-03-16T10:30:00.445Z","data":{"sslTierStats":{"rxSSLMbps":0,"rxSSLMaxMbps":0,"rxSSLPktsPerSec":0,"rxSSLMaxPktsPerSec":0,"txSSLMbps":0,"txSSLMaxMbps":0,"txSSLPktsPerSec":0,"txSSLMaxPktsPerSec":0},"npSslI...
Raw field value: "{"created":"2024-03-16T18:22:56.258Z","deviceSerial":"55036","deviceId":"00066","bundle":[{"category":"ExtTlsTelemetry","created":"2024-03-16T10:30:00.445Z","data":{"sslTierStats":{"rxSSLMbps":0,"rxSSLMaxMbps":0,"rxSSLPktsPerSec":0,"rxSSLMaxPktsPerSec":0,"txSSLMbps":0,"txSSLMaxMbps":0,"txSSLPktsPerSec":0,"txSSLMaxPktsPerSec":0},"npSslInspTrafficStats":{"clientBytesIn":0,"clientPacketsIn":0,"serverBytesIn":0,"serverPacketsIn":0,"clientBytesToD":0,"clientPacketsToD":0,"clientBytesToI":0,"clientPacketsToI":0,"serverBytesToD":0,"serverPacketsToD":0,"serverBytesToI":0,"serverPacketsToI":0},"npSslInspStats":{"sslConnections":0,"sslRuleConnections":0,"sslNoRuleConnections":0,"inspectedSessions":0,"shuntedSessions":0,"blockedMaxSslConnections":0,"allowedMaxSslConnections":0,"maxSessions":0,"percentMaxSessions":0,"blockedCriticalBigHeapUse":0,"allowedCriticalBigHeapUse":0},"sslConcurrentConnections":0,"sslProxyConfig":{"nUniqueCerts":0,"nUniqueCidrs":0,"serverAddresses":[],"certificateInfo":{}}}}]}"

  at io.github.spark_redshift_community.spark.redshift.RedshiftWriter.$anonfun$doRedshiftLoad$2(RedshiftWriter.scala:200)

This is the main error:
Error (code 1224) while loading data into Redshift: "Format with multiple values without array or object"
This is the data I'm trying to insert (valid json string):
{"created":"2024-03-16T18:22:56.258Z","deviceSerial":"55036","deviceId":"00066","bundle":[{"category":"ExtTlsTelemetry","created":"2024-03-16T10:30:00.445Z","data":{"sslTierStats":{"rxSSLMbps":0,"rxSSLMaxMbps":0,"rxSSLPktsPerSec":0,"rxSSLMaxPktsPerSec":0,"txSSLMbps":0,"txSSLMaxMbps":0,"txSSLPktsPerSec":0,"txSSLMaxPktsPerSec":0},"npSslInspTrafficStats":{"clientBytesIn":0,"clientPacketsIn":0,"serverBytesIn":0,"serverPacketsIn":0,"clientBytesToD":0,"clientPacketsToD":0,"clientBytesToI":0,"clientPacketsToI":0,"serverBytesToD":0,"serverPacketsToD":0,"serverBytesToI":0,"serverPacketsToI":0},"npSslInspStats":{"sslConnections":0,"sslRuleConnections":0,"sslNoRuleConnections":0,"inspectedSessions":0,"shuntedSessions":0,"blockedMaxSslConnections":0,"allowedMaxSslConnections":0,"maxSessions":0,"percentMaxSessions":0,"blockedCriticalBigHeapUse":0,"allowedCriticalBigHeapUse":0},"sslConcurrentConnections":0,"sslProxyConfig":{"nUniqueCerts":0,"nUniqueCidrs":0,"serverAddresses":[],"certificateInfo":{}}}}]}

This is my corresponding DDL for table PUBLIC.telemetry_data:
create table public.telemetry_data
(
    telemetry     super encode zstd
);

Environment details
Package version:
        <dependency>
            <groupId>io.github.spark-redshift-community</groupId>
            <artifactId>spark-redshift_2.12</artifactId>
            <version>6.2.0-spark_3.5</version>
        </dependency>

the same issue. Is there any solution?

@vnktsh You can check the public docs for examples on how to use the SUPER data type with the connector: https://docs.aws.amazon.com/redshift/latest/mgmt/spark-redshift-connector-data-types.html


Where to set ICE Candidate generate by remote？

After calling peerConnection.createAnswer() on the H5 side, the 'icecandidate' event of the peerConnection returned an ICE Candidate, like this:
{"candidate":"candidate:1 1 TCP<PHONE_NUMBER> <IP_ADDRESS> 9 typ host tcptype active","sdpMid":"video","sdpMLineIndex":0,"usernameFragment":"c976a1ab"}
However, I haven't found how to set the ICE Candidate data in libpeer?

I am working on add_ice_candidate should have PR soon!


symbol(s) not found for architecture x86_64

I'm trying to run bgfx with sdl2 and so far I'm almost there I think.
I already compiled bgfx and included it on my cmake, I'm running macos 10.15.5.
But when I try to run this code c++
#include <SDL2/SDL.h>
#include <SDL2/SDL_syswm.h>
#include <bgfx/bgfx.h>
#include <bgfx/platform.h>
#include <stdio.h>

SDL_Window *window = NULL;
const int WIDTH = 640;
const int HEIGHT = 480;

int main() {

  // Initialize SDL systems
  if (SDL_Init(SDL_INIT_VIDEO) < 0) {
    printf("SDL could not initialize! SDL_Error: %s\n", SDL_GetError());
  } else {
    //Create a window
    window = SDL_CreateWindow(
      "BGFX Tutorial",
      SDL_WINDOWPOS_UNDEFINED,
      SDL_WINDOWPOS_UNDEFINED,
      WIDTH,
      HEIGHT,
      SDL_WINDOW_SHOWN);
    if (window == NULL) {
      printf("Window could not be created! SDL_Error: %s\n", SDL_GetError());
    }
  }

  // Collect information about the window from SDL
  SDL_SysWMinfo wmi;
  SDL_VERSION(&wmi.version);
  if (!SDL_GetWindowWMInfo(window, &wmi)) {
    return 1;
  }

  bgfx::PlatformData pd;

#if BX_PLATFORM_LINUX || BX_PLATFORM_BSD
  pd.ndt = wmi.info.x11.display;
  pd.nwh = (void *)(uintptr_t)wmi.info.x11.window;
#elif BX_PLATFORM_OSX
  pd.ndt = NULL;
  pd.nwh = wmi.info.cocoa.window;
#elif BX_PLATFORM_WINDOWS
  pd.ndt = NULL;
  pd.nwh = wmi.info.win.window;
#elif BX_PLATFORM_STEAMLINK
  pd.ndt = wmi.info.vivante.display;
  pd.nwh = wmi.info.vivante.window;
#endif

  // Tell bgfx about the platform and window
  bgfx::setPlatformData(pd);

  // Poll for events and wait till user closes window
  bool quit = false;
  SDL_Event currentEvent;
  while (!quit) {
    while (SDL_PollEvent(&currentEvent) != 0) {
      if (currentEvent.type == SDL_QUIT) {
        quit = true;
      }
    }
  }

  // Free up window
  SDL_DestroyWindow(window);
  // Shutdown SDL
  SDL_Quit();

  return 0;
}

I get the following error
Scanning dependencies of target prototype
[  7%] Building CXX object CMakeFiles/prototype.dir/src/main.cpp.o
In file included from /Users/miguel/src/prototype/src/main.cpp:3:
/Users/miguel/src/prototype/include/bgfx/include/bgfx/bgfx.h:419:9: warning: 'CallbackI' has no out-of-line virtual method
      definitions; its vtable will be emitted in every translation unit [-Wweak-vtables]
        struct CallbackI
               ^
1 warning generated.
[ 15%] Linking CXX executable prototype
Undefined symbols for architecture x86_64:
  "bgfx::PlatformData::PlatformData()", referenced from:
      _main in main.cpp.o
  "bgfx::setPlatformData(bgfx::PlatformData const&)", referenced from:
      _main in main.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [prototype] Error 1
make[1]: *** [CMakeFiles/prototype.dir/all] Error 2
make: *** [all] Error 2

Maybe the issue it's on my cmake?
I think I need to link the build?
cmake_minimum_required (VERSION 3.17.2)
project(prototype)

include_directories("include/bx/include")
include_directories("include/bimg/include")
include_directories("include/bgfx/include")

IF(APPLE)
  include_directories("/usr/local/include")
  set(CMAKE_CXX_COMPILER "/usr/bin/clang++")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_THREAD_SAFE")
ENDIF()

# Idea taken from https://github.com/CraftSpider/GCDecompiler/blob/master/CMakeLists.txt
file(GLOB_RECURSE HEADERS CONFIGURE_DEPENDS src/*.hpp)
file(GLOB_RECURSE SOURCES CONFIGURE_DEPENDS src/*.cpp)

set(ALL_CODE ${HEADERS} ${SOURCES})

add_executable(${PROJECT_NAME} ${ALL_CODE})

IF(APPLE)
  set(SDL_CXX_FLAGS "-L/usr/local/lib -lSDL2_image -lSDL2")
  target_link_libraries(${PROJECT_NAME} ${SDL_CXX_FLAGS})
ENDIF()

target_compile_features(${PROJECT_NAME} PRIVATE cxx_std_20)
target_compile_options(${PROJECT_NAME}
  PRIVATE
    -Wall -Wextra -Wpedantic -Wfatal-errors -Wshadow -Iinclude
    -Wweak-vtables -Wmissing-noreturn -Wunreachable-code
)

This is probably an issue on your part, but I recommend you trying https://github.com/widberg/bgfx.cmake as it's already tested and it works.


Make Start (and make build-docker) fail

I am running CentOS 7. I've successfully built Neutron as instructed. However, when I run make start or make build-docker I get the same error:
make start
go run neutron.go
github.com/emersion/neutron/backend/imap
backend/imap/attachments.go:40: undefined: imap.NewSeqSet
backend/imap/events.go:40: undefined: imap.NewSeqSet
backend/imap/messages.go:44: undefined: imap.NewSeqSet
backend/imap/messages.go:159: undefined: imap.NewSeqSet
backend/imap/messages.go:389: undefined: imap.NewSeqSet
backend/imap/messages.go:532: undefined: imap.NewSeqSet
make: *** [start] Error 2
Thanks for any assistance!

Got the same error, haven't found a solution yet.

This is caused by a go-imap breaking change. I just pushed a fix for neutron!
Neutron should really use either glide or dep to pin dependencies and prevent such issues.


Use asm 9.4.

https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/pull/806

Build failed https://gradle.com/s/awt7qwbwfl3hg

@autonomousapps Try running it again, (for my local time) I see the failed build ran at ~2 AM and I see that asm-relocated ended up on Central at ~7 AM (5 hours later). https://repo.maven.apache.org/maven2/com/autonomousapps/asm-relocated/<IP_ADDRESS>/


Refactor fine grained scheduling and support multiple offers per slave.

Changed YarnNodeCapacityManager to only handle capacity related operations.
Moved rest of the functionalities into following classes:

OfferFeed: Queues up offers.
OfferLifecycleManager: Manages offers that have been consumed by Myriad.
NMHeartBeatHandler: Handles NM heart beat.
NodeStore: Tracks the nodes that are part of Myriad.

Testing:
Ran word count

Merging this into the feature branch issue_14 to update PR #91


JSC_USELESS_CODE: Suspicious code. This code lacks side-effects

When I try to compile with google closure compiler it gives me a warning:
JSC_USELESS_CODE: Suspicious code. This code lacks side-effects. Is there a bug?
The problem comes from this code:
if (pattern && label && /^Win/i.test(os) &&
    (data = data[0/*Opera 9.25 fix*/, /[\d.]+$/.exec(os)])) {
  os = 'Windows ' + data;
}

Basically from this
data = data[0/*Opera 9.25 fix*/, /[\d.]+$/.exec(os)])

because this is an assignment and not an condition.
Might be fixed in the future versions.
Thanks

It was put in place for Opera 9.25 but we can drop that now.

nice. Also there is a similar error on this code, same line with opera
function getManufacturer(guesses) {
      return reduce(guesses, function(result, value, key) {
        // lookup the manufacturer by product or scan the UA for the manufacturer
        return result || (
          value[product] ||
          value[0/*Opera 9.25 fix*/, /^[a-z]+(?: +[a-z]+\b)*/i.exec(product)] ||
          RegExp('\\b' + qualify(key) + '(?:\\b|\\w*\\d)', 'i').exec(ua)
        ) && key;
      });
    }


Test flake: TestMySQLDatastoreWithTablePrefix/TestWatch

--- FAIL: TestMySQLDatastoreWithTablePrefix (41.42s)
    --- FAIL: TestMySQLDatastoreWithTablePrefix/TestWatch (2.66s)
        --- FAIL: TestMySQLDatastoreWithTablePrefix/TestWatch/256 (2.12s)
            watch.go:154:
                	Error Trace:	/home/runner/work/spicedb/spicedb/internal/datastore/mysql/watch.go:154
                	            				/home/runner/work/spicedb/spicedb/internal/datastore/mysql/watch.go:112
                	Error:      	Should be false
                	Test:       	TestMySQLDatastoreWithTablePrefix/TestWatch/256

First seen in https://github.com/authzed/spicedb/pull/775 (https://github.com/authzed/spicedb/runs/8140232574?check_suite_focus=true)

Saw again:
--- FAIL: TestMySQLDatastore (67.57s)
    --- FAIL: TestMySQLDatastore/TestWatch (2.17s)
        --- FAIL: TestMySQLDatastore/TestWatch/256 (1.58s)
            watch.go:154:
                	Error Trace:	/home/runner/work/spicedb/spicedb/internal/datastore/mysql/watch.go:154
                	            				/home/runner/work/spicedb/spicedb/internal/datastore/mysql/watch.go:112
                	Error:      	Should be false
                	Test:       	TestMySQLDatastore/TestWatch/256
                	```

Is this still valid? I see test are passing on local env

Just ran via stress:
6m0s: 20 runs so far, 0 failures
6m5s: 20 runs so far, 0 failures
6m10s: 20 runs so far, 0 failures
6m15s: 20 runs so far, 0 failures
6m20s: 20 runs so far, 0 failures

Will reopen if we see this flake again


Make 2018-01-01 as default for all clients

Make package-2018-01 as the default for all clients. package-2018-06-preview is still in development and can have breaking changes. Hence we dont want any clients to be built on top of that.
Inspired from the comment https://github.com/Azure/azure-sdk-for-net/pull/4652#pullrequestreview-145389712
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-ruby

Please see: I did not change anything for the Java Client, still, they are appearing as diff. Just changed the Basic Information
@dsgouda FYI

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node


Correction for raw affiliation LAB'URBA; École d'urbanisme de Paris

Correction needed for raw affiliation LAB'URBA; École d'urbanisme de Paris
raw_affiliation_name: LAB'URBA; École d'urbanisme de Paris
new_rors:
previous_rors: 03mwypp50
works_examples: W4391917441
contact: ab9b7c425ce5907cf26a6387c9191c1b:f5001fa3457ce7acfa1dbc46873b43 @ recherche.gouv.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-09. The new affiliations should be visible within the next 7 days.


kernel: support non-identity RAM mapping

Some platforms may have multiple RAM regions which are
dis-continuous in the physical memory map. We really want
these to be in a continuous virtual region, and we need to
stop assuming that there is just one SRAM region that is
identity-mapped.
We no longer use CONFIG_SRAM_BASE_ADDRESS and CONFIG_SRAM_SIZE
as the bounds of kernel RAM, and no longer assume in the core
kernel that these are identity mapped at boot.
Two new Kconfigs, CONFIG_KERNEL_VM_BASE and
CONFIG_KERNEL_RAM_SIZE now indicate the bounds of this region
in virtual memory.
We are currently only memory-mapping physical device driver
MMIO regions so we do not need virtual-to-physical calculations
to re-map RAM yet. When the time comes an architecture interface
will be defined for this.
Platforms which just have one RAM region may continue to
identity-map it.
Signed-off-by: Andrew Boie<EMAIL_ADDRESS>

This patch was inspired by discussion in https://github.com/zephyrproject-rtos/zephyr/pull/29348 where it became clear to me that we shouldn't assume a single contiguous physical RAM region, and we need to allow (but not strictly require) non identity kernel mappings for RAM.

https://github.com/zephyrproject-rtos/zephyr/blob/fbc487cce34c9c417b302432701966753c9f9e17/tests/arch/x86/pagetables/src/main.c#L19-L20
You probably want to tweak these lines as well.


Add stoi guard

Andy,
This fixes wrapper process dying in case of an stoi failure when reading 'iter' from the ifs.stat file. Adds new function and guard code before the conversion of iter.  In the case of bad iter values, it is reset to 'last_iter.
Could also be used in other places in the code where an stoi is about to be performed on, possibly corrupt, data is read from a file.
Have tested this with one of Clement's tasks using boinc running standalone. Tested by suspending master.exe process and manually adding corrupt line to ifs.stat. Wrapper correctly caught it and carried on.
Best,  Glenn

Hi Glenn,
I see you have changed the executable name back to 'master.exe', is that what you wanted to do?

Hi Andy,  I'd prefer to leave it as oifs_43r3.exe but wasn't sure if you had changed the 'apps' to use oifs_43r3.exe yet?


[INLONG-3629][Agent] Improve TestFileAgent unit test

Title Name: [INLONG-3629][Agent] Improve TestFileAgent unit test
where XYZ should be replaced by the actual issue number.
Fixes #3629
Motivation
Explain here the context, and why you're making that change. What is the problem you're trying to solve?
Modifications
Describe the modifications you've done.
Verifying this change
(Please pick either of the following options)

[ ] This change is a trivial rework/code cleanup without any test coverage.

[ ] This change is already covered by existing tests, such as:
(please describe tests)

[ ] This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a follow-up issue for adding the documentation

please fix this UT at the same time.


Feature/fix file descriptor leakage

This fix closes ioReadCloser's after their usage to stop file descriptors being leaked.
Also fies dependabot alert for hashicorp/nomad.

 Fix file descriptor resource leakage in dp-deployer


Implement a symfony/mailer handler

As swiftmailer is abandoned many of us are "forced" to search for an alternative. The recommended alternative is symfony/mailer.
I'm not using the Symfony Framework but only the symfony/mailer. I know there is an implementation inside the monolog-bridge. But the monolog-bridge has some dependencies which I absolutely not need e.g. symfony/http-kernel. So i don't want to require the monolog-bridge as I'm only missing the monolog handler.
Is there a chance we could get an implementation directly inside the monolog package like with the swiftmailer handler?

AFAIK the monolog package itself has stopped accepting handlers that rely on additional dependencies, as it makes it very hard to manage dependencies (the monolog package cannot require those dependencies, as it would annoy all projects not using that handler). That's also why the wiki has a list of third-party packages related to monolog.

Ok thank you for your answer. That makes sense! I'll take a look at an alternative approach.

Yeah for this I think I may want to make an exception though as email support is kinda core IMO and just relying on mail() makes for a poor UX.
SwiftMailerHandler needs to be deprecated, and MandrillHandler also relies on SwiftMailer being present to build a message so this would need to be updated too.

If someone wants to help with this that'd be great btw.

I'll answer @dmitry-ivanov's question here. It's true that we don't use Symfony's Mailer directly, just the transports. It's because we already have our own Mailer class with its send method. Changing it would be a really big breaking change to our users.
I'm not too familiar with Monolog's handlers or inner workings so I'm not sure I can answer what's needed to make this work on the Laravel side of things.

Please note that with the current implementation of monolog-bridge there is an issue when using SmtpTransport related to the fact that Symfony Mailer use monolog to log in the stop method https://github.com/symfony/symfony/blob/6.1/src/Symfony/Component/Mailer/Transport/Smtp/SmtpTransport.php
https://github.com/symfony/monolog-bundle/issues/405

See https://github.com/Seldaek/monolog/pull/1663


Add ARM support

Hi,
Not sure if this is the right repo to create this issue in but it would be great to have ARM support added to the logdna/logdna-agent Docker image. Cloud providers are pushing ARM quite heavily these days and we've had to build our own LogDNA image with multi-arch support using the old Node agent so we can continue using your product.

Good point @mogggggg !
Supporting ARM64 is high on our priority list.
I'll keep this open and ping you when it's scheduled to be released.
cc @mogggggg

cc @alfeng6

Hi @jorgebay, has there been any progress on this?

@jorgebay,
PR raised for adding arm64 support is merged but arm64 image is not yet released in dockerhub.
May I know when are you planning to release arm64 image in dockerhub?

Maybe @alfeng6 @c-nixon can give more details about the arm64 support release plan.

Any update on this? It looks like support for ARM was added a while ago but still needs to be added to the CI config

This is in the works now, @mogggggg.  We should be releasing it in the next week or two.

Have it been released? :eyes:

Would ❤  arm64 support. Just tried installing the LogDNA agent on my Raspberry Pi Kubernetes cluster via Helm and failed with:
standard_init_linux.go:228: exec user process caused: exec format error

Has it been released? 👀 cc: @mogggggg

I'd say we're waiting for https://github.com/logdna/build-images/pull/26

@gjanco any update on when this is expected to be released?

May I know when are you planning to release arm64 image in dockerhub?

Hi, we hope to have them out with 3.5 which we plan to release a beta for in the next week or 2

I'll close this now since it's been released and we're using it 🎉


fix: components-helper version update

update the components-helper version

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/1.3.1@64e4532). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head e167b25 differs from pull request most recent head 66f7a0f. Consider uploading reports for the commit 66f7a0f to get more accurate results

@@               Coverage Diff                @@
##             release/1.3.1     #925   +/-   ##
================================================
  Coverage                 ?   57.14%
================================================
  Files                    ?        1
  Lines                    ?       70
  Branches                 ?       15
================================================
  Hits                     ?       40
  Misses                   ?       30
  Partials                 ?        0

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 64e4532...66f7a0f. Read the comment docs.


Test out new build for paho.mqtt.rust

A new build system for paho.mqtt.rust has been released.
Let's upgrade any services using paho.mqtt.rust to the new build system and see how they work.  This will help advance the testing for that project.
See https://github.com/eclipse/paho.mqtt.rust/issues/3

We're now using rumqtt


Version 2.0.0 Release Merge

Version 2.0.0 Release Merge

We love releases you're doing such a great job ❤

Thanks, sir


Questions regarding attention masks in the ParlerTTSDecoder code

I have been reading through the code to understand the attention masking patterns and I have a few questions.
First, when running the code with the default hyperparams, I get the following warning during the forward pass of the ParlerTTSDecoder:
"prompt_attention_mask is specified but attention_mask is not. A full attention_mask will be created. Make sure this is the intended behaviour."
I am unsure whether this is intended behavior or not and would appreciate a clarification. At face value, it seems incorrect since there should ideally be a real attention_mask that masks out the audio pad tokens. I see some docstrings in the code that say that the decoder_attention_mask is optional and by default masks out the pad token ids, but I could not find whether this actually happens in the code (and if it did, the warning should not have appeared).
Second, I notice that the pad_token_id is the same as the eos_token_id in the decoder config at https://huggingface.co/parler-tts/parler_tts_mini_v0.1/blob/main/config.json . Is masking correctly handled such that the token at the EOS position is not masked out, but the tokens at the PAD positions are, even though the token IDs are the same for both?

I have the same problem

Same here:
prompt_attention_mask is specified but attention_mask is not. A full attention_mask will be created. Make sure this is the intended behaviour.
Additionally, with flash-attn temporarily uninstalled:
UserWarning: 1Torch was not compiled with flash attention. (Triggered internally at C:\actions-runner_work\pytorch\pytorch\builder\windows\pytorch\aten\src\ATen\native\transformers\cuda\sdp_utils.cpp:555.)
attn_output = torch.nn.functional.scaled_dot_product_attention(
while: attn_implementation = "sdpa"

Same here. I have not been able to find a way to get around the warning either (prompt_attention_mask is specified but attention_mask is not. A full attention_mask will be created. Make sure this is the intended behaviour.)
Is it safe to ignore or does it have some unexpected consequences?


Introduce index for retrieving last active access token

An index should be introduced to the following query
[1] - https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/v6.2.58/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/dao/SQLQueries.java#L665-L670

https://github.com/wso2/product-is/issues/6929

Should be closed once the migration client is updated


Nodes getting stuck at Block Height 1

Node is getting stuck at Block Height:1 and Max observed length: 1

Logs are attached.
2021-01-14_23-07-28.tar.gz

Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]16ebdd6597ab050fdaf8a075cc39d9b7be1233cf

Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]16ebdd6597ab050fdaf8a075cc39d9b7be1233cf

Also, I noticed about 10 more people with the same problem.

Also, I noticed about 10 more people with the same problem.

I have the same issue. On a previously running node (has been running and fine for 24 hours), I restarted the mina service and now it's stuck at block height 1/observed 1.
ii  mina-testnet-postake-medium-curves 0.2.2-1-b14e324                             amd64        Mina Client and Daemon
/usr/local/bin/coda daemon -peer-list-file /root/peers.txt -insecure-rest-server  -generate-genesis-proof true -log-level Info -file-log-level Info -super-catchup
Thu Jan 14 23:16:54 UTC 2021
{"timestamp":"2021-01-14 23:16:55.119336Z","level":"Debug","source":{"module":"Block_time","location":"File \"src/lib/block_time/block_time.ml\", line 76, characters 18-30"},"message":"Environment variable CODA_TIME_OFFSET not found, using default of 0","metadata":{"pid":20844}}
Coda daemon status
-----------------------------------

Global number of accounts:                     2026
Block height:                                  1
Max observed block length:                     1
Local uptime:                                  6m42s
Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]b14e32415b15af04865ca069af31cea7716be251
Configuration directory:                       /root/.coda-config
Peers (36):
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBKR3xmcXf5gLEALko46kdLbZDs9jnGq7Dwx9oC6He19A
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWJvu72HWg75664JXEPLrZT7H4P7KccX9qXeo6Endo4KGo
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWDrVn96LC9WF9U4BRYG2g8YvsQet5bdFFzohzj3ZzLQQG
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWRmXR8V8FxzxQu9fkyaMTqoP7QETH5t2UZBMV5sEFmWR5
        /ip4/<IP_ADDRESS>/tcp/10510/p2p/12D3KooWPXFnvusqHaKuuuUX5w54C6TKfXv7MQVrtnXDEsjS4Zcn
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWH3y8JbMK54yCM7JQLKsksHvxcXPBskrohCa8yV138dnF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWHmxRoubY3HfXw3HhoMe8z9bQ5kyGVGQsCHwdvpWX7Xsf
        /ip4/<IP_ADDRESS>/tcp/10001/p2p/12D3KooWJ9mNdbUXUpUNeMnejRumKzmQF15YeWwAPAhTAWB6dhiv
        /ip4/<IP_ADDRESS>/tcp/10520/p2p/12D3KooWSkr77aJSMAWo7XnzcoMsfXEcq2ccsqiZkMWdyTSL3fWz
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWMT2jSJKtKZmTUJJYKmUsfHVTZkpqeLAnaFbyuQtMUyzj
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooW9yCf9R6zqrpAWUqgyV3tnXFM7EwbYEd1WmXinTmjaWeW
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWMHowmYFe39zdcUjaot3XPjjGWwA37KEp43kJrAmBNWVM
        /ip4/<IP_ADDRESS>/tcp/10518/p2p/12D3KooWQUjcrUAH5PnZKKTQ1ece6ZASgMJwzEXuUk9P4mytwYys
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWQdynGruWxWkoEacmB8SdWo6oRFQVAkwJU8gg7u6PDhRF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWSPT3FfqZDNQXymNUbfnCZrkvWbKEKf9HJKC25RUQLZ2j
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWDHfsARmB8Z95H2qWiPnfU387LAfx5yB3Wf6bduZe9CDS
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBZQepY3gCwdjufkWDn9qRLosRVb2xr7gHwDhkycXsD79
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWKfPpiGnM4LMQhY6R7ehCLr3WHj3GB1em5ep9rJ1Sfrn6
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWG7NJ4ym48xzR4PxGQrfHCVRVZYEJsSnEfx4rRQE6qtWr
        /ip4/<IP_ADDRESS>/tcp/10506/p2p/12D3KooWHHgxmedmJbeqhE3ee1FEEaVkrJG9yfAsjdAeDbdspVWm
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWH6whDiPwAK7bcenWJdQ3KWC5LqmQjeqq8632HmUTBDyc
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPPACyFgxg5kbC4roUxEDDupDnedYyUPocpJS34VTuJZW
        /ip4/<IP_ADDRESS>/tcp/10507/p2p/12D3KooWKX4PKkC6NuVjVLvanutK3uc5BzAojCHwqW65oKksh6UN
        /ip4/<IP_ADDRESS>/tcp/10519/p2p/12D3KooWLRMHRQNLdXpmb2ZBFoPU6Vtt9vizGmEaR8qY6bbPnutW
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWNvdPDv6AYNuVbbuWq9M1Gf6pD1np6MmUHhWrKSt8ViRj
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBYSTSRWviRJz3MhsfMEweKrXcG5V37pJyf4yJ9dXMwqF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWEHrafQnjaDLYYXfRXKYC7AgHhYPePMLQvFxUYSUmYSws
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWRcBbpMEfkk4gyYk5Cny3wJfoVS96wHEXXML7HQ4NMW9Q
        /ip4/<IP_ADDRESS>/tcp/10517/p2p/12D3KooWDuVf77qd61T1332hqCvJWTDMkhrMuqoTiK9h29vjBgF9
        /ip4/<IP_ADDRESS>/tcp/10511/p2p/12D3KooWEFMJM3ru7q6pGWqei1RCcJTxdsHx6dGGXWntkxnJDkC2
        /ip4/<IP_ADDRESS>/tcp/10909/p2p/12D3KooWAFFq2yEQFFzhU5dt64AWqawRuomG9hL8rSmm5vxhAsgr
        /ip4/<IP_ADDRESS>/tcp/10508/p2p/12D3KooWFBNsTGhuH8pMcQhL5aZoFFjTedCZUtPSuevRPhvaZPXh
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBz78QM3Wvzzn8n6gau93jqmvMDtjr6qYahKcbrFc1eoG
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPq3jQJGjSSsTmX8bu8VkEQDy1EhveHudE3oYPPgdh2xC
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPFMw2RK25FXqC6gEAVMWXovtmv8hxwB1Cvo8nLMduQLR
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWQ88Ajpa73ZqoPZSNXQaU7x4ihRzJVXiP885UfPwaAZ1E
User_commands sent:                            0
SNARK worker:                                  None
SNARK work fee:                                25000000
Sync status:                                   Synced
Catchup status:
        Finished:  1

Block producers running:                       0
Best tip consensus time:                       epoch=0, slot=0
Best tip global slot (across all hard-forks):  0
Next block will be produced in:                None this epoch… checking at in 14.582d
Consensus time now:                            epoch=1, slot=140
Consensus mechanism:                           proof_of_stake
Consensus configuration:
        Delta:                     0
        k:                         290
        Slots per epoch:           7140
        Slot duration:             3m
        Epoch duration:            14d21h
        Chain start timestamp:     2020-12-30 19:14:30.000000Z
        Acceptable network delay:  3m

I have the same issue. On a previously running node (has been running and fine for 24 hours), I restarted the mina service and now it's stuck at block height 1/observed 1.
ii  mina-testnet-postake-medium-curves 0.2.2-1-b14e324                             amd64        Mina Client and Daemon
/usr/local/bin/coda daemon -peer-list-file /root/peers.txt -insecure-rest-server  -generate-genesis-proof true -log-level Info -file-log-level Info -super-catchup
Thu Jan 14 23:16:54 UTC 2021
{"timestamp":"2021-01-14 23:16:55.119336Z","level":"Debug","source":{"module":"Block_time","location":"File \"src/lib/block_time/block_time.ml\", line 76, characters 18-30"},"message":"Environment variable CODA_TIME_OFFSET not found, using default of 0","metadata":{"pid":20844}}
Coda daemon status
-----------------------------------

Global number of accounts:                     2026
Block height:                                  1
Max observed block length:                     1
Local uptime:                                  6m42s
Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]b14e32415b15af04865ca069af31cea7716be251
Configuration directory:                       /root/.coda-config
Peers (36):
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBKR3xmcXf5gLEALko46kdLbZDs9jnGq7Dwx9oC6He19A
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWJvu72HWg75664JXEPLrZT7H4P7KccX9qXeo6Endo4KGo
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWDrVn96LC9WF9U4BRYG2g8YvsQet5bdFFzohzj3ZzLQQG
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWRmXR8V8FxzxQu9fkyaMTqoP7QETH5t2UZBMV5sEFmWR5
        /ip4/<IP_ADDRESS>/tcp/10510/p2p/12D3KooWPXFnvusqHaKuuuUX5w54C6TKfXv7MQVrtnXDEsjS4Zcn
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWH3y8JbMK54yCM7JQLKsksHvxcXPBskrohCa8yV138dnF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWHmxRoubY3HfXw3HhoMe8z9bQ5kyGVGQsCHwdvpWX7Xsf
        /ip4/<IP_ADDRESS>/tcp/10001/p2p/12D3KooWJ9mNdbUXUpUNeMnejRumKzmQF15YeWwAPAhTAWB6dhiv
        /ip4/<IP_ADDRESS>/tcp/10520/p2p/12D3KooWSkr77aJSMAWo7XnzcoMsfXEcq2ccsqiZkMWdyTSL3fWz
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWMT2jSJKtKZmTUJJYKmUsfHVTZkpqeLAnaFbyuQtMUyzj
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooW9yCf9R6zqrpAWUqgyV3tnXFM7EwbYEd1WmXinTmjaWeW
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWMHowmYFe39zdcUjaot3XPjjGWwA37KEp43kJrAmBNWVM
        /ip4/<IP_ADDRESS>/tcp/10518/p2p/12D3KooWQUjcrUAH5PnZKKTQ1ece6ZASgMJwzEXuUk9P4mytwYys
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWQdynGruWxWkoEacmB8SdWo6oRFQVAkwJU8gg7u6PDhRF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWSPT3FfqZDNQXymNUbfnCZrkvWbKEKf9HJKC25RUQLZ2j
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWDHfsARmB8Z95H2qWiPnfU387LAfx5yB3Wf6bduZe9CDS
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBZQepY3gCwdjufkWDn9qRLosRVb2xr7gHwDhkycXsD79
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWKfPpiGnM4LMQhY6R7ehCLr3WHj3GB1em5ep9rJ1Sfrn6
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWG7NJ4ym48xzR4PxGQrfHCVRVZYEJsSnEfx4rRQE6qtWr
        /ip4/<IP_ADDRESS>/tcp/10506/p2p/12D3KooWHHgxmedmJbeqhE3ee1FEEaVkrJG9yfAsjdAeDbdspVWm
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWH6whDiPwAK7bcenWJdQ3KWC5LqmQjeqq8632HmUTBDyc
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPPACyFgxg5kbC4roUxEDDupDnedYyUPocpJS34VTuJZW
        /ip4/<IP_ADDRESS>/tcp/10507/p2p/12D3KooWKX4PKkC6NuVjVLvanutK3uc5BzAojCHwqW65oKksh6UN
        /ip4/<IP_ADDRESS>/tcp/10519/p2p/12D3KooWLRMHRQNLdXpmb2ZBFoPU6Vtt9vizGmEaR8qY6bbPnutW
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWNvdPDv6AYNuVbbuWq9M1Gf6pD1np6MmUHhWrKSt8ViRj
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBYSTSRWviRJz3MhsfMEweKrXcG5V37pJyf4yJ9dXMwqF
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWEHrafQnjaDLYYXfRXKYC7AgHhYPePMLQvFxUYSUmYSws
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWRcBbpMEfkk4gyYk5Cny3wJfoVS96wHEXXML7HQ4NMW9Q
        /ip4/<IP_ADDRESS>/tcp/10517/p2p/12D3KooWDuVf77qd61T1332hqCvJWTDMkhrMuqoTiK9h29vjBgF9
        /ip4/<IP_ADDRESS>/tcp/10511/p2p/12D3KooWEFMJM3ru7q6pGWqei1RCcJTxdsHx6dGGXWntkxnJDkC2
        /ip4/<IP_ADDRESS>/tcp/10909/p2p/12D3KooWAFFq2yEQFFzhU5dt64AWqawRuomG9hL8rSmm5vxhAsgr
        /ip4/<IP_ADDRESS>/tcp/10508/p2p/12D3KooWFBNsTGhuH8pMcQhL5aZoFFjTedCZUtPSuevRPhvaZPXh
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWBz78QM3Wvzzn8n6gau93jqmvMDtjr6qYahKcbrFc1eoG
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPq3jQJGjSSsTmX8bu8VkEQDy1EhveHudE3oYPPgdh2xC
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWPFMw2RK25FXqC6gEAVMWXovtmv8hxwB1Cvo8nLMduQLR
        /ip4/<IP_ADDRESS>/tcp/8302/p2p/12D3KooWQ88Ajpa73ZqoPZSNXQaU7x4ihRzJVXiP885UfPwaAZ1E
User_commands sent:                            0
SNARK worker:                                  None
SNARK work fee:                                25000000
Sync status:                                   Synced
Catchup status:
        Finished:  1

Block producers running:                       0
Best tip consensus time:                       epoch=0, slot=0
Best tip global slot (across all hard-forks):  0
Next block will be produced in:                None this epoch… checking at in 14.582d
Consensus time now:                            epoch=1, slot=140
Consensus mechanism:                           proof_of_stake
Consensus configuration:
        Delta:                     0
        k:                         290
        Slots per epoch:           7140
        Slot duration:             3m
        Epoch duration:            14d21h
        Chain start timestamp:     2020-12-30 19:14:30.000000Z
        Acceptable network delay:  3m

On a new node on a separate cloud provider, I am seeing something similar.
ii  mina-testnet-postake-medium-curves 0.2.4-16ebdd6                               amd64        Mina Client and Daemon
root@mina-testworld-dev-2:~$ coda client status
{"timestamp":"2021-01-14 23:19:28.271772Z","level":"Debug","source":{"module":"Block_time","location":"File \"src/lib/block_time/block_time.ml\", line 76, characters 18-30"},"message":"Environment variable CODA_TIME_OFFSET not found, using default of 0","metadata":{"pid":13857}}
Coda daemon status
-----------------------------------

Global number of accounts:                     2026
Block height:                                  1
Max observed block length:                     1
Local uptime:                                  28m
Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]16ebdd6597ab050fdaf8a075cc39d9b7be1233cf
Configuration directory:                       /root/.coda-config
Peers:                                         50
User_commands sent:                            0
SNARK worker:                                  None
SNARK work fee:                                25000000
Sync status:                                   Synced
Catchup status:
        Finished:  1

Block producers running:                       0
Best tip consensus time:                       epoch=0, slot=0
Best tip global slot (across all hard-forks):  0
Next block will be produced in:                None this epoch… checking at in 14.58d
Consensus time now:                            epoch=1, slot=141
Consensus mechanism:                           proof_of_stake
Consensus configuration:
        Delta:                     0
        k:                         290
        Slots per epoch:           7140
        Slot duration:             3m
        Epoch duration:            14d21h
        Chain start timestamp:     2020-12-30 19:14:30.000000Z
        Acceptable network delay:  3m

Addresses and ports:
        External IP:    <IP_ADDRESS>
        Bind IP:        <IP_ADDRESS>
        Libp2p PeerID:  12D3KooWMZZaxXgQMHpy41cBwav3TbrGsJnpyDMFRyZCW1vx9dyj
        Libp2p port:    8302
        Client port:    8301

On a new node on a separate cloud provider, I am seeing something similar.
ii  mina-testnet-postake-medium-curves 0.2.4-16ebdd6                               amd64        Mina Client and Daemon
root@mina-testworld-dev-2:~$ coda client status
{"timestamp":"2021-01-14 23:19:28.271772Z","level":"Debug","source":{"module":"Block_time","location":"File \"src/lib/block_time/block_time.ml\", line 76, characters 18-30"},"message":"Environment variable CODA_TIME_OFFSET not found, using default of 0","metadata":{"pid":13857}}
Coda daemon status
-----------------------------------

Global number of accounts:                     2026
Block height:                                  1
Max observed block length:                     1
Local uptime:                                  28m
Ledger Merkle root:                            jxX6VJ84HaafrKozFRA4qjnni4aPXqXC2H5vQLKSryNpKTXuz1R
Protocol state hash:                           3NLxYrjb7zmHdoFgBrubCN8ijM8v7eT8kvLiPLc9DHt3M8XrDDEG
Chain id:                                      2dbac725ebb5c6c8b1daf21cda9e3694951ab72afe9be99ff7ca47574112f43b
Git SHA-1:                                     [DIRTY]16ebdd6597ab050fdaf8a075cc39d9b7be1233cf
Configuration directory:                       /root/.coda-config
Peers:                                         50
User_commands sent:                            0
SNARK worker:                                  None
SNARK work fee:                                25000000
Sync status:                                   Synced
Catchup status:
        Finished:  1

Block producers running:                       0
Best tip consensus time:                       epoch=0, slot=0
Best tip global slot (across all hard-forks):  0
Next block will be produced in:                None this epoch… checking at in 14.58d
Consensus time now:                            epoch=1, slot=141
Consensus mechanism:                           proof_of_stake
Consensus configuration:
        Delta:                     0
        k:                         290
        Slots per epoch:           7140
        Slot duration:             3m
        Epoch duration:            14d21h
        Chain start timestamp:     2020-12-30 19:14:30.000000Z
        Acceptable network delay:  3m

Addresses and ports:
        External IP:    <IP_ADDRESS>
        Bind IP:        <IP_ADDRESS>
        Libp2p PeerID:  12D3KooWMZZaxXgQMHpy41cBwav3TbrGsJnpyDMFRyZCW1vx9dyj
        Libp2p port:    8302
        Client port:    8301

2021-01-14_23-08-56.tar.gz

2021-01-14_23-08-56.tar.gz

Issue is fixed on Commit [DIRTY]d44a1339bdbdd5ebe747124c7146f435a3f73453

Issue is fixed on Commit [DIRTY]d44a1339bdbdd5ebe747124c7146f435a3f73453

thank you but how do you get 453 ?
[image: image.png]
On Thu, Jan 14, 2021 at 9:42 PM Raghul Raj<EMAIL_ADDRESS>wrote:

[image: image]
https://user-images.githubusercontent.com/1759429/104674216-1d359280-5698-11eb-9333-bb1fb9bea8de.png
Issue is fixed on Commit [DIRTY]d44a1339bdbdd5ebe747124c7146f435a3f73453
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MinaProtocol/mina/issues/7497#issuecomment-760607462,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLJOUHSTXMEIMA44W2BK73SZ6TRPANCNFSM4WDG5CCA
.

thank you but how do you get 453 ?
[image: image.png]
On Thu, Jan 14, 2021 at 9:42 PM Raghul Raj<EMAIL_ADDRESS>wrote:

[image: image]
https://user-images.githubusercontent.com/1759429/104674216-1d359280-5698-11eb-9333-bb1fb9bea8de.png
Issue is fixed on Commit [DIRTY]d44a1339bdbdd5ebe747124c7146f435a3f73453
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MinaProtocol/mina/issues/7497#issuecomment-760607462,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASLJOUHSTXMEIMA44W2BK73SZ6TRPANCNFSM4WDG5CCA
.

This has already fixed by #7494

This has already fixed by #7494


[Network] Fix ExpressRoute live test

The ExpressRoute service updated the service to return a useful error message rather than "An error occured." Updated the test to check for this new error.

Codecov Report

Merging #2600 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2600   +/-   ##
=======================================
  Coverage   72.58%   72.58%
=======================================
  Files         374      374
  Lines       20297    20297
  Branches     2971     2971
=======================================
  Hits        14732    14732
- Misses       4638     4642    +4
+ Partials      927      923    -4

Impacted Files
Coverage Δ

...-cli-role/azure/cli/command_modules/role/custom.py
17.89% <0%> (ø)
:arrow_up:

src/azure-cli-core/azure/cli/core/_util.py
66.66% <0%> (ø)
:arrow_up:

...dback/azure/cli/command_modules/feedback/custom.py
34.69% <0%> (ø)
: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 4c8780a...121c962. Read the comment docs.