"is having a problem responding right now" with every bot message only on facebook

After I upgraded the bot to V3 everythings seems to work, I use skype channel, web chat and facebook, on all the channels the bot is working as expected, except with facebook, after every message the bot sends back, there is another message that says " is having a problem responding right now"
I have already used /deleteprofile command and the problem still happends.
The status of the channels is "Running".

Can you share you the Microsoft App Id of your bot?

Sure, the App Id is "99e647a2-f3cd-46cb-826c-beac3e1cd85e"

Can you add your bot handle?

You might try going to the facebook configuration page and resubmitting your credentials.

Bot handle "ParceroProduction".
I did removed the credentials and resubmit them. I also removed the webhook on the facebook app and reconfigured it. I just notice today that some messages in the facebook channel are sent twice.

I just notice this error in the status of the channel
Facebook graph API call failed with: BadRequest {"error":{"message":"(#194) param [elements] has too few elements.","type":"OAuthException","code":194,"fbtrace_id":"Hz7T5FoCxCl"}}

I deleted the bot and recreate it, created new application Id and everything and the problem keeps showing, new handle "Parcerobot" new Microsoft App Id "c5982bc8-c332-4a82-8ff6-1630027a2283"

I finally found the problem, there was an error in a dialog serialization. I fixed the dialog and the problem disappeared. I do not understand why the problem was only reflected on the facebook channel.

apuyana, I'm having the same issue can you elaborate on what you did to fix it.

@MCKRUZ I found the problem by adding a Try/Catch on the service entry point, the exception message was that the dialog I was creating had enviroment variables that could not be serialized
So to fix it I changed the root dialog creation from:
await Conversation.SendAsync(activity, () => { return MakeRoot(activity); });
to:
await Conversation.SendAsync(activity, MakeRoot);
I needed the activity in the dialog because when I created a replay message from the IDialogContext, some field were null, so in the end I fixed the problem in the CreateReplay method and that way did not need the activity.
Check the fixes in my branch https://github.com/anuracode/BotBuilder

Sorry, I have the same problem on nodeJS SDK can you suggest a solution language independent?

@fcioffi The fix I made was in the creation of the replay message I completed the values of ServiceUrl and ChannelId that were null and not copied.
I am now using the Microsoft.Bot.Builder nuget package 3.5.1 and do not have this problem.
Hope this helps


Fix backdrop blur support rule

supports-backdrop-blur:bg-background/60 does nothing
supports-[backdrop-filter]:bg-background/60 does something!
see: https://github.com/shadcn-ui/ui/pull/1628

Thanks for this @ollema !


Handling of procedure locals allocations and deallocations

This PR adds handling of allocations and deallocations for procedure locals in the new Assembler structure.

the only point to think about is if the prologue/epilogue of the span builder isn't going to be an exclusive construction of the procedure (to define the number of locals).

I think we can keep it more general for now. There might be other instances when we want to have wrappers around code blocks - though, I can't come up with any specific ones at the moment.


Case Insensitive Search is Case Sensitive

I have a HTML file which I'm reading as string: https://pastebin.pl/view/0068acb8
Looking at the docs: https://jsoup.org/apidocs/org/jsoup/select/Selector.html
The contains should be case insensitive but from my tests it is.
I'm using version 1.14.2.
String str = GetFileAsString.get();
Document doc = Jsoup.parse(str);
String inner = doc.selectFirst("*:contains(test)").text();

returns no results
String inner = doc.selectFirst("*:contains(Test)").text();
Returns a single result.
I would expect both to return a single result.
Is there something I'm missing?

Elements result = doc.getElementsContainingOwnText("Test"); // Single result
Elements result = doc.getElementsContainingOwnText("test"); // Single result

Both return a single result.
doc.selectFirst("*:contains(test)").text(); // No result
doc.selectFirst("*:contains(Test)").text(); // Single result

It's like the cssQuery is case sensitive when it shouldn't be.

Hi -- I see that you closed this, can you let us know the resolution? Did you find an issue in your code, or is there still an issue here, or?


Button Link text color change when visited

Issue Description
The text of terra-button components changes to a blue color if it links to another page after the page has been visited.

Issue Type

[ ] New Feature
[ ] Enhancement
[x] Bug
[ ] Other

Expected Behavior

The Button should continually display with the same color text (white in my case)
Current Behavior

Buttons are now displaying with blue text after their link has been visited

Steps to Reproduce

Create a terra button component with an href
Visit the link
Go back to original page to see new text color

Environment

Component Version: Not completely sure, but I believe its the Terra-Base (version 2.11.0)
Browser Name and Version: Chrome Version 63.0.3239.132 & Firefox 58.0.1 (64-bit)
Operating System and version (desktop or mobile): macOS Sierra Version 10.12.6 (desktop)

Any updates on this?

We've identified the root cause on this. When we added global styles to all hyperlinks to update them to the OCS colors, we didn't account for needing to updated styles for the link pseudo-classes for our components that render as anchors. We've logged #1215 to dig into the underlying issue, it looks like terra-button is the only terra-core component to get hit by this bug.
We added these styles in terra-base v2.11.0.
To fix the issue in our code, we'll be adding a selector in terra-button to account for there now being global styles applied to a:visited to ensure those styles don't impact the terra-button when it is rendered as an anchor and a user has visited the anchor's href URL before.
With the current state of button in terra-core we are planning to release terra-button v2 shortly. This would mean to get the fix for this as a consumer, your apps would need to update to terra-button v2. As this may be a bigger ask than anticipated to get the bug fix, I am considering the steps we'd need to take to do a back patch release of terra-button v1.14.1 to resolve this in the v1 version of terra-button.
To help test against this issue with global link styles in the future, we'll be adding screenshot tests for button's rendered as anchors in all of the various pseudo-class states (:focus, :hover, :visited, :active) similar to how we are capturing screenshots for hyperlinks rendered in all of these states.
If we add other components where we control the rendering and are rendering anchors, we'll add screenshot testing to test all the pseudo-class states as well

This bug exists currently in our code for button v2 and will need to be fixed before we release<EMAIL_ADDRESS>

@bjankord Thanks for the update. Just FYI, this seems to be affecting other anchor links in our app as well besides button link. See image below.
The profile links on the bottom left are supposed to be black, but they are now blue because of visited styles. I feel that's something your team might want to take into account as well. I understand that we can change the visited color by setting css variable --terra-link-visted-color, but that will take a global effect and impact all anchor links. We might want different link colors in different area of our app.

also, thanks to @kafkahw noting that css variable, isn't it mispelled?
https://github.com/cerner/terra-core/blob/3f58fa9fff3f0be26305534b03ca54a11aa2ad4a/packages/terra-base/src/Base.scss#L45
a.is-visited {
  color: var(--terra-link-visted-color, #0065a3);
}

visited vs
visted

These has been resolved in<EMAIL_ADDRESS>We've reverted the global link styles in the path release. We will be creating an anchor component in the future to provide a way to style links as the UX team intends.
<EMAIL_ADDRESS>is now released and available on npm. cc/ @grneggandsam  @kafkahw


Plugin Reader Metadata Does Not Standardize Supported Suffixes

Describe the Bug

Found while working on understanding #55 (#54): Some reader metadata files include leading . while others do not. This results in our plugin cache having duplicate entries for what is the same suffix.
For example:

bioio-ome-tiff INCLUDES a leading period
bioio-tiff-glob INCLUDES a leading period
bioio-ome-zarr INCLUDES a leading period

No other readers do however.

bioio-tifffile
bioio-imageio
etc.

This causes problems during plugin parsing and organization on the bioio side because we create our plugin cache based off of the suffixes. If bioio-tifffile and bioio-ome-tiff both list tiff and .tiff respectively in their reader_metadata files. That will create two entries rather than one.
Expected Behavior

I don't think we can always trust that the plugin authors will follow a standard regarding some arbitrary suffix information. Instead we can do some minor clean up during plugin cache creation time to either always remove or always add a leading period.
Reproduction

Add print statements checking for leading "." during plugin cache creation (my debug prints), or, print the plugin cache after creation and look for duplicate suffixes.

Actually, I see that this was already being done at determine_plugin time, however since we would still prefer to not have duplicate suffixes in the plugin cache, I think it's still better to handle this earlier in the stack.

is this part of https://github.com/bioio-devs/bioio/pull/55

Yes I will handle as part of my existing pull request


Windows: Always enable VT emulation

Always enable VT output emulation when starting the process so that non-attaching commands can still output VT codes.
Also remove the version block for using the native console and just rely on supported flags being present. This version block doesn't really achieve anything anymore and is just noise in the long run, since these flags were only broken in a few interim Windows builds.
To verify:
Run docker pull with and without the change. Without the change, you'll see something like:
C:\Windows\system32>docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
Last layer "031c24a19e4b1631a74dff3fda414aa92792d2a484bd60a3bf4d5ea600a2351a" does not have a base layer reference

(Note the �[0B)
With the change, you won't see the extra VT codes:
C:\Windows\system32>dockerfixed pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
Last layer "031c24a19e4b1631a74dff3fda414aa92792d2a484bd60a3bf4d5ea600a2351a" does not have a base layer reference

cc/@jhowardmsft

You beat me to it - there's a bug on my plate to do exactly this. Looks good in principle, but needs golint run in the changes before moving to code review.

Pushed a golint fix. TP5 is failing now, but I think it's spurious.

LGTM

SGTM

https://jenkins.dockerproject.org/job/Docker-PRs-Win2Lin/28476/console
9:38:35
19:38:35 ----------------------------------------------------------------------
19:38:35 FAIL: docker_cli_build_test.go:6431: DockerSuite.TestBuildLabelOneNode
19:38:35
19:38:35 docker_cli_build_test.go:6443:
19:38:35     c.Fatal(err)
19:38:35 ... Error: invalid character 'r' after top-level value
19:38:35
19:38:36
19:38:36 ----------------------------------------------------------------------

I believe these tests passed when I originally submitted the PR. This is some kind of JSON parsing error, which doesn't seem like it could have been caused by this change. Can we retry?

restarted win2lin

ping @tiborvass is this ok to merge, or would this make cherry-picking for 1.12 more difficult for you?

Would indeed prefer waiting for after 1.12.0. We'll do a PR review marathon after the release and this will be an easy one to merge.

My only concern with waiting for post 1.12.0 is that users might start hitting this bug a lot more often once the Windows 10 Anniversary Update is released on August 2. Anyone using the Docker CLI on Windows 10 (even if targeting a Linux daemon) will hit it.

Temporarily putting this back in "code review" to prevent accidental merge. For reference; PR is all green, so we can merge when possible

@jstarks GA is planned for July 28, would that still give you enough time for  Windows 10 Anniversary Update ?

Users will start getting the Windows 10 update on August 2 (not everyone will get it immediately, the roll out will take some time). This update adds full (enough) support for VT100 in Windows, and in Docker 1.12 we changed the code to start using this feature when it's available instead of falling back to the console emulator that we wrote in Go. Without this fix, though, the VT100 feature does not get enabled for Docker commands such as docker pull, which causes weird output.
So if we want the latest stable Windows 10 and the latest stable Docker releases to work well together, I think we need this fix for 1.12.0. This bug doesn't affect Docker 1.11, so users on older supported versions of Docker will be fine.

@jstarks ok. LGTM

Thanks


Implement global app config/state plumbing

We might want to expose some global configuration/state object in the app to store all sorts of things, from settings to feature flags and other related app state.
chatbot is suggesting using Context API for that.
https://react.dev/learn/passing-data-deeply-with-context

The Context API allows you to share global state, without needing to pass props through multiple levels. You would create a context, then use a context provider to wrap the parts of your tree that need access to that context.
Here's a simplified example:
import React, { createContext, useContext, useState } from 'react';

// Create a context
export const ConfigContext = createContext();

// Create a provider which will hold the state
export const ConfigProvider = ({ children }) => {
  const [config, setConfig] = useState({
    setting1: true,
    setting2: false,
  });

  return (
    <ConfigContext.Provider value={[config, setConfig]}>
      {children}
    </ConfigContext.Provider>
  );
};

// Create a custom hook for convenience, so you can get the config easily from any component
export const useConfig = () => {
  return useContext(ConfigContext);
};

Then in your application root, you would wrap your application in the ConfigProvider:
import { ConfigProvider } from './ConfigContext';

function App() {
  return (
    <ConfigProvider>
      <YourAppHere />
    </ConfigProvider>
  );
}

Now, in any component in your application, you can access the config state and the setConfig function using the useConfig hook:
import { useConfig } from './ConfigContext';

function SomeComponent() {
  const [config, setConfig] = useConfig();

  // Access values in the config
  console.log(config.setting1);

  // Update the config
  setConfig({ ...config, setting1: false });

  return
Some component
;
}

Keep in mind, while the Context API is great for small applications, for more complex applications with a lot of state management, you may want to consider using Redux or MobX, which offer more features out-of-the-box and might help in structuring your application in a more maintainable way.


Allow Non UTF-8 Lookups In Bencode Dictionary

Also includes updates to bip_bencode, bip_dht, and bip_metainfo to use error-chain. Obligatory rustfmt was run on all crates as well making some commits a bit noisy.
Ref #60

Closes #60


Class 'Orchestra\Testbench\TestCase' not found in /var/www/api/vendor/barryvdh/laravel-cors/tests/TestCase.php on line 5

I cannot run phpunit anymore. It gives me this error:

Class 'Orchestra\Testbench\TestCase' not found in /var/www/api/vendor/barryvdh/laravel-cors/tests/TestCase.php on line 5

structure issue in test folder

@aconital what was the structure issue exactly?

I came across this issue today. I wanted a subfolder /tests/Api to run tests from, and loaded it into my autoloader via psr4. I missed namespacing one of my tests in the root /tests folder, and it triggered this error in my barryvdh package. Once I namespaced the test in ran without a problem.


[Feature] Improvement in data processed/cost incurred in insert_overwrite method

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt-bigquery functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Currently, in static as well as dynamic insert_overwrite, when on_schema_change is set to anything other than ignore, a temporary table is created, then that temporary table is used in the merge statement.
E.g. (Dynamic insert_overwrite)
create or replace table `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

partition by datetime_trunc(createddate, day)

OPTIONS(
expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 12 hour)
)
as (

SELECT
*
FROM
`dummy_project`.`source_dataset`.`the_table`

-- this filter will only be applied on an incremental run
WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
and UpdatedDate >= '2023-02-20 19:00:01.873000'

);

-- generated script to merge partitions into `dummy_project`.`target_dataset`.`the_table`
declare dbt_partitions_for_replacement array<datetime>;

  -- 1. temp table already exists, we used it to check for schema changes
-- 2. define partitions to update
set (dbt_partitions_for_replacement) = (
    select as struct
        -- IGNORE NULLS: this needs to be aligned to _dbt_max_partition, which ignores null
        array_agg(distinct datetime_trunc(createddate, day) IGNORE NULLS)
    from `dummy_project`.`target_dataset`.`the_table__dbt_tmp`
);

-- 3. run the merge statement

merge into `dummy_project`.`target_dataset`.`the_table` as DBT_INTERNAL_DEST
  using (
  select
  * from `dummy_project`.`target_dataset`.`the_table__dbt_tmp`
) as DBT_INTERNAL_SOURCE
  on FALSE

when not matched by source
   and datetime_trunc(DBT_INTERNAL_DEST.createddate, day) in unnest(dbt_partitions_for_replacement)
  then delete

when not matched then insert
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')
values
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')

;

-- 4. clean up the temp table
drop table if exists `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

In the current setup, the query for temporary table is run for schema comparison, then the temporary table is used later.
So let's say temporary table query processes 5 GB of data and makes a temp table of 500 MB. Since the temp table is selected again during the merge process, total data processed would be 5 GB + 500 MB = 5.5 GB
Describe alternatives you've considered
My idea is to create a temp table, but with LIMIT 0, so the data processed for schema comparison is always 0 MB. Later, the query used for temporary table creation can be used directly within the merge statement, this way the additional cost of selecting temp table again won't be involved. So in my above example, the data processed would only be 5 GB.
Sample query
create or replace table `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

partition by datetime_trunc(createddate, day)

OPTIONS(
expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 12 hour)
)
as (

SELECT
*
FROM
`dummy_project`.`source_dataset`.`the_table`

-- this filter will only be applied on an incremental run
WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
and UpdatedDate >= '2023-02-20 19:00:01.873000'

) LIMIT 0; -- 0 MB processed here

-- generated script to merge partitions into `dummy_project`.`target_dataset`.`the_table`
declare dbt_partitions_for_replacement array<datetime>;

  -- 1. temp table already exists, we used it to check for schema changes
-- 2. define partitions to update
set (dbt_partitions_for_replacement) = (
    select as struct
        -- IGNORE NULLS: this needs to be aligned to _dbt_max_partition, which ignores null
        array_agg(distinct datetime_trunc(createddate, day) IGNORE NULLS)
    from `dummy_project`.`target_dataset`.`the_table__dbt_tmp`
);

-- 3. run the merge statement

merge into `dummy_project`.`target_dataset`.`the_table` as DBT_INTERNAL_DEST
  using (
  SELECT
      *
  FROM
      `dummy_project`.`source_dataset`.`the_table`

  -- this filter will only be applied on an incremental run
  WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
  and UpdatedDate >= '2023-02-20 19:00:01.873000'
) as DBT_INTERNAL_SOURCE
  on FALSE

when not matched by source
   and datetime_trunc(DBT_INTERNAL_DEST.createddate, day) in unnest(dbt_partitions_for_replacement)
  then delete

when not matched then insert
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')
values
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')

;

-- 4. clean up the temp table
drop table if exists `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

Depending on how big the temporary table is, cost savings would wary.
Who will this benefit?
Everyone using insert_overwrite would see lower costs in BigQuery
Are you interested in contributing this feature?
Yes
Anything else?
No response

In your offered change, you would like to create an empty tmp_table as you assume it's only used for schema change but actually it's also use to know on which partition restrict the actual MERGE statement
set (dbt_partitions_for_replacement) = (
    select as struct
        -- IGNORE NULLS: this needs to be aligned to _dbt_max_partition, which ignores null
        array_agg(distinct datetime_trunc(createddate, day) IGNORE NULLS)
    from `dummy_project`.`target_dataset`.`the_table__dbt_tmp`
);

If you skip that, then your merge statement cost might skyrocket because it won't "prune" the partitions that are not eligible for merge.
You're better off using copy_partition option in insert_overwrite strategy as it won't bill you the merge too.

@github-christophe-oudar I went through your comment as well as the DBT query when copy_partition is set to True.
2 things I would like to point out:

I admit, I had overlooked the temp table being used in dbt_partitions_for_replacement part to find modified partitions.

But with a slight modification of the query, we can make this work while keeping the cost saving benefit. This involves modifying dbt_partitions_for_replacement to use the original query itself instead of the temp table. Since we are selecting only CreatedDate column in outer query with pruning in WHERE condition, cost would be roughly the same as selecting CreatedDate from the temp table. Below is the full modified query:
create or replace table `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

partition by datetime_trunc(createddate, day)

OPTIONS(
expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 12 hour)
)
as (

SELECT
*
FROM
`dummy_project`.`source_dataset`.`the_table`

-- this filter will only be applied on an incremental run
WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
and UpdatedDate >= '2023-02-20 19:00:01.873000'

) LIMIT 0; -- 0 MB processed here

-- generated script to merge partitions into `dummy_project`.`target_dataset`.`the_table`
declare dbt_partitions_for_replacement array<datetime>;

  -- 1. temp table already exists, we used it to check for schema changes
-- 2. define partitions to update
set (dbt_partitions_for_replacement) = (
    select as struct
        -- IGNORE NULLS: this needs to be aligned to _dbt_max_partition, which ignores null
        array_agg(distinct datetime_trunc(createddate, day) IGNORE NULLS)
    from (

SELECT
*
FROM
`dummy_project`.`source_dataset`.`the_table`

-- this filter will only be applied on an incremental run
WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
and UpdatedDate >= '2023-02-20 19:00:01.873000'

) -- full query being re-used here
);

-- 3. run the merge statement

merge into `dummy_project`.`target_dataset`.`the_table` as DBT_INTERNAL_DEST
  using (
  SELECT
      *
  FROM
      `dummy_project`.`source_dataset`.`the_table`

  -- this filter will only be applied on an incremental run
  WHERE date(CreatedDate) in ('2023-02-01', '2023-02-02')
  and UpdatedDate >= '2023-02-20 19:00:01.873000'
) as DBT_INTERNAL_SOURCE
  on FALSE

when not matched by source
   and datetime_trunc(DBT_INTERNAL_DEST.createddate, day) in unnest(dbt_partitions_for_replacement)
  then delete

when not matched then insert
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')
values
  (`Column 1`, `Column 2`, `Column 3`, 'CreatedDate', 'UpdatedDate')

;

-- 4. clean up the temp table
drop table if exists `dummy_project`.`target_dataset`.`the_table__dbt_tmp`

The copy_partitions method as you said, avoids data scanning of the merge process. So for this case, it is necessary to create temp table with data in it, as the partitions of the temp table are used later to replace partitions in the main table.

So I see 2 ways to move forward:

We apply the logic I've provided only when incremental_strategy is insert_overwrite and copy_partitions is False. We can also apply this logic when incremental_strategy is merge, in which case copy_partitions cannot be set to True. In both cases, we will see some cost savings compared to the existing setup.

We leave the code as it is, without any modification.

Personally, I do see some benefit in the modified logic, but I'll leave it to you to make the final call. No pressure. 🙂

Since we are selecting only CreatedDate column in outer query with pruning in WHERE condition, cost would be roughly the same as selecting CreatedDate from the temp table

I agree that it would work for a simple query but that would work but in some cases that include joins, windows functions and/or aggregations, I don't think it will costs that less.
Let's assume we have a query (on a column with a date & a number), that costs: 1 GB for the full query, 500 MB for the partition selection and 1 MB output (eg a group by date and SUM).
Then in that case, current solution would mean 1 GB (original query) + 1 MB (reading temp table) + 100 MB (the merge)
whereas your approach would use 1 GB (original query) + 500 MB (query "optimized" for selected column) + 100 MB (the merge) which would be higher.
My point is that it's not always better to either of those approaches.

So let's say temporary table query processes 5 GB of data and makes a temp table of 500 MB. Since the temp table is selected again during the merge process, total data processed would be 5 GB + 500 MB = 5.5 GB

I think that statement assumes that the destination table is empty too as MERGE statement on a non empty table is not free too.
I understand there are cases where it could be better but there's also case where it could be worse and I don't know which is ones are the most common.
Also I'm not the one making the call in the end 🙃
So I'll let the dbt Labs team figuring out if it's worth it.
You might also look into bringing another option that would let the end user customize the behavior to fit their needs but making it the default could be felt as a regression for those have models such as my example.
Finally, you're also assuming most dbt users are using "per query pricing" and not "slot time pricing" which might also change a lot the actual outcome of that change.

@github-christophe-oudar
I agree that it would work for a simple query but in some cases that include joins, windows functions and/or aggregations, I don't think it will costs that less.

In some scenarios where window functions are involved or perhaps some complex left joins, I agree finding dbt_partitions_for_replacement using my logic could cost more compared to existing query for that, but the additional cost would only be for one column i.e. CreatedDate. We are saving temp table cost completely where all columns are selected in the previous step. Based on the data scanned in source table and data generated in the target, cost consumed might swing either way, so there is an uncertainty here.
But one thing that's for sure is that, at least for static insert_overwrite and merge methods of incremental_strategy, my logic would save costs in 100% of on-demand scenarios, as finding date partitions isn't involved in that process.
I think that statement assumes that the destination table is empty too as MERGE statement on a non empty table is not free too.
I had simplified in the example. Destination table being empty or non-empty would not modify cost incurred in the existing logic or my proposed logic, as we aren't modifying how data is merged with destination. Cost incurred as far the destination table is concerned would be the same in both cases.
Finally, you're also assuming most dbt users are using "per query pricing" and not "slot time pricing" which might also change a lot the actual outcome of that change.
In slot time pricing, the charges are fixed. Based on the compute, query time might increase or decrease. Based on my understanding(not 100% sure, but I've roughly seen this), more data scanned == more compute, so if we manage to reduce data scanned, compute time should also reduce in most cases as it has less data to process. Cost would remain the same regardless.
Anyway, I understand that optimizing cost at the expense of everything else(in this case, increased code complexity) might not always be preferred, so I'm perfectly fine if this is marked as not planned. 🙂


DELIA-47123: Split BTMGR_Init and BTRMGR_DeInit

Reason for change: Modify rdkservices to reflect BTRMGR changes.
Test Procedure: Activate Bluetooth service, activate System service,
see no IARM errors in log.
Risks: Low
Signed-off-by: Nikita Poltorapavlo<EMAIL_ADDRESS>

moves #506 to 2101

@anand-ky, please merge


Dapper and FakeItEasy are presented as separate projects

Problem
I have a dotnet api that uses dapper in my api project, and FakeItEasy as a test framwork in my test projects. But those get separate coverage results like so:

Expected Behaviour
Only my main csproj project (along with the test projects themselves should be covered), not Dapper and FakeItEasy as they are simple dependencies.

Is this maybe something wrong with my solution setup?
Has anyone else encountered this problem?

If not, I will make a public repo to replicate this problem.

Versions

"Dapper" Version="2.0.123" (referenced from api-project)
"FakeItEasy" Version="7.2.0" (referenced from test-project)
"Microsoft.CodeCoverage" Version="17.8.0" (referenced from api-project only)
Dotnet 6

By the way, I got here because of your blog on devblogs.microsoft.com.

Please refer to this scenario to exclude third party dependencies in the coverage report. https://github.com/microsoft/codecoverage/blob/main/samples/Calculator/scenarios/scenario06/README.md

We will probably work on some automatic exclusion as part of: https://github.com/microsoft/codecoverage/issues/72
Closing this one

Thank you! Scenario6 fixed it!


NIFI-6510 - Support enable disable of prediction in ui

Updated the Connection summary table to only show the prediction column if predictions are available
Updated back pressure tooltips to indicate a distinction between Queue Prediction not being configured and not able to make a prediction just yet.

Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
Enables X functionality; fixes bug NIFI-YYYY.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[X] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[X] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[X] Has your PR been rebased against the latest commit within the target branch (typically master)?

[X] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] Have you verified that the full build is successful on both JDK 8 and JDK 11?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Will review...

Change look good here too. +1

Thanks @rfellows for helping with this. Merging into the branch


Put pronouns in video chat name

May need a redesign given our nowrap settings for long emoji names. Maybe on a second line?

This is blocked on #465, we don't have pronoun data at runtime unless you actively /look at someone

Pending a discussion of video

Videochat? What's that?


0.6

clicked the wrong button. lol. sorry

0.6?! LOL :)

I tried to follow
https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser
to sync my fork
wanted to cancel but the UI was loading too slow. then there was the create PR button under the cursor, where a sec earlier was cancel. :D
I am trying to write a Redis CDC Connector for DBZ over the weekend (challenge myself). Realized there's a replication log that wants to be captured ;)

I did it on the console afterwards. I guess I'm not that UI guy

I am trying to write a Redis CDC Connector for DBZ over the weekend
(challenge myself). Realized there's a replication log that wants to be
captured ;)

That's funny, just was thinking about Redis the other day. If you do
something, make sure to take a look at how the SQL Server connector is
implemented (ChangeEventSource et. al) as it's the blueprint for any
connectors going forward (we're trying to unify more and more code across
connectors, but it's still in flux...).
Am Mi., 29. Mai 2019 um 21:43 Uhr schrieb René Kerner <
<EMAIL_ADDRESS>
I did it on the console afterwards. I guess I'm not that UI guy
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/debezium/debezium/pull/895?email_source=notifications&email_token=AAAG7RAY6KOQWRJWPA4LJWLPX3META5CNFSM4HQSMEV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQN4HI#issuecomment-497081885,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAG7RC4YYK6DPUWAJGUQP3PX3METANCNFSM4HQSMEVQ
.


Add reactivity adapter for cellx

https://github.com/Riim/cellx

I've checked the api and I don't think that it is possible with the current architecture of signaldb to implement a simple reactitvity adapter for cellx


Implement Display models for QualifiedConcept

A stepping stone to #1682. Builds on #1715.

Looks good to me except the test thing and I'd rather get to a common agreement on how we write these tests before adopting this pattern everywhere


without genome guide assembly

This assembly software without genome-guide assembly model

Scallop is a genome-guide (or reference-based) transcript assembler, which means that reads need to be aligned to the reference genome before assembling.

Currently Scallop does not use the existing reference annotation transcriptome; we will implement this in the later releases.


test(integration/system-backup): check latest backup in if-not-present volume backup policy

Which issue(s) this PR fixes:

Issue longhorn/longhorn#6027
What this PR does / why we need it:
Extend the existing test case to support longhorn/longhorn#6027. The if-not-present backup policy should also create volume backup when the last backup is outdated.
Special notes for your reviewer:
None
Additional documentation or context
https://github.com/longhorn/longhorn-tests/pull/1388#discussion_r1210663186

@coderabbitai review


Update workflow to be used in merge queue.

Resolves: #2419
Note:
This is more complicated as expected unfortunately, as having a workflow that runs only in the queue is not straightforward.
Currently, what I read up and tested, this is how it should work:
-> workflow is triggered on PR event AND merge_group event
-> jobs only should run when it's really queued (not for e.g. opening a PR)
-> job still needs to be triggered by required checks AND required merge groups
This does not seem to work as expected, though, because while the last test run only merged after the required jobs where done, it seems like on the test-main branch another job failed later. This could have been due to timing though and needs more investigation.
Will keep this Draft open for now, but it's not merge ready yet.

Closing this, as there's currently no time to work on it & the repo is not super active, so we can stay at our current pipeline for now.


Question

Has anyone ever gotten this to work? I can't seem to make it scan or add any device.

I haven't updated this in a very long time, I really don't have the time for it these days. it's very possible it has become too outdated to still function


Python 3 support

LicenseFinder breaks in virtualenv environments where python is actually Python 3.

Fixed in df4e36962ab.  Please test.  Will be released in version 2.0.2.  In the meantime, you can pin to this SHA.

Version 2.0.2 released.


[Bug] Crash in reader while updating library

Device information

Neko version: 2.1.3
Android phone & version: OnePlus 5T, LineageOS 16.0 (Android 9), MicroG

Steps to reproduce

Run global library update
While update is still running, go into browse section
Open manga and start reading
Crash occured after a short period of time, or only reading a few pages

Expected behavior
Swiping screen turns to next page in manga
Actual behavior
Screen freezes and home/app switcher don't work. Locking screen and unlocking unfreezes the home/app switcher. Going to home screen causes android to show that Neko has crashed and should be closed.
Other details
I changed the logs to Extra and repeated steps to get crash.
Link: https://pastebin.com/UYYLUzXv
I tried reading manga while the library wasn't updating and the crash didn't happen, so I believe that the library updating may have had an influence on the crash.

Same thing happens to me on the past few versions of the app. I believe it first started when i updated from <IP_ADDRESS> to 2.1.3.
I've noticed that if instead of refreshing the whole library, I just refresh a category with a handful of few manga then it works fine. But if the number of manga in a category is quite large then it will crash, just like if trying to refresh the whole library.
Sometimes instead of crashing, it will just timeout/glitch out and not update the manga. I've verified this by trying to do an update, no crash but didn't update anything, then I manually clicked refresh on individual manga and it found new chapters.

Does this happen on the most recent version from yesterday @jaredanson ?  I modified the code some for the 429 error.  So it might have effected this

@CarlosEsco yes it still happens. I double checked before posting that i was on the newest version, and attempted to refresh the whole library. Doing so the app frozen, and Android prompted me to kill it or wait.

I haven't checked the logic in the recent releases. Did you modify the number of threads/coroutines or some logic around using them? It feels like app is using up all the resources on the phone when there is a lot of manga in the library.

what device and specs?    Latest version is just using 1 thread i got rid of some of the extra processing that jay originally added to j2k and i had modified some.

Pixel 2 XL and Android 10, and i'm on the latest version of the app.

how many manga roughly do you have?  How many merged?

@CarlosEsco what does merged mean?

And i've got 504 manga in my library +/- a few, i was quickly counting by rows of 3.

thanks.  and in future ungroup the library, long press a manga then press the dot top left to select all 😄

lmao yeah i figured there was some easy way to do it. But i didn't think it would take that long to count up the rows, but when i got to over 150 rows I was wishing i had looked for the method you mentioned.

My library is just short of 2500, so that could be part of the problem.

@CarlosEsco I noticed another idiosyncrasy about this. If i update a small category and then click to update another small category, which adds to the queue, both of those will pass even though the combined amount is larger than single categories that will fail/freeze up when trying to update.

I've added 2-3 categories to the queue and it works. When big single categories don't

@CarlosEsco went manga by manga in the big category seeing if maybe there was some type of issue with a manga entry that was causing the updater to freeze up. That ended up being the case, and luckily it was only one manga so i didn't have to keep searching through the list. When i updated this single manga it caused my phone to lock up and freak out. It was some manga i didn't care about, and after removing it I'm able to update my whole library without any problems.
Obviously going manga by manga trying to figure out which one has an issue is a pain, especially in the case of that other guy who has almost 2,500 entries.

i initially thought it was some type of thread issue since it was crashing the app and because previous bugs with updating entries just caused an update failure, and not locking up the app/phone. But after fixing it by removing that single manga, it seems to point to some type of an handled exception.

@jaredanson was the manga merged at all ?

@CarlosEsco i don't know what that means, so i assume no.

It was some manga I randomly added, I never read or did anything with it.

You should probably share what that manga was so it can be debugged.

I tracked down the manga that was doing it for me.
I just started a library update in alphabetical order and checked what manga the notification froze on when the app crashed.
This is what broke the app for me, even when just updating it by itself. There were a couple failed updates, but only this one would completely crash the app when attempting to update.
Now that I've removed that one, I was able to go through an entire library update without the app crashing, and with a notification actually showing up.

should be fixed in <IP_ADDRESS>

Yep, it's working for me. Thank you!


Refactor ways

Currently we have two expressions getLibWays and getRtsWays defined in Settings/Ways.hs. They mirror make variables GhcLibWays and GhcRtsWays, respectively.
I propose to merge the expressions into one named getWays. We will then be able to use the standard Predicate-based mechanism to work with rts-specific ways. For example, the following expression tells us that by default we use vanilla and profiling for libraries, and threadedProfiling for rts:
defaultWays :: Ways
defaultWays = mconcat
    [ libraryPackage ? append [vanilla, profiling]
    , package rts    ? append [threadedProfiling] ]

If need be we can always extract rts-specific ways as follows:
getRtsWays :: Ways
getRtsWays = package rts ? getWays

However, we probably will not even have to do this, as correct ways will automatically be computed for each target via interpret target getWays.
This is a pretty straightforward change but I'd like to document it here for future reference. Let me know if you have any concerns about this.

This should be done before #98.

After experimenting with the proposed approach I decided not to proceed with it. Although it is indeed possible to merge all ways into one expression, the resulting code is much more difficult to understand and customise for user's needs. We stay with two expressions: getLibraryWays and getRtsWays.


Additional entry in header file

The header file does not specify whether an article is in Simple German, German, or both.

Fixed it


Add support for Java 9 multi release jars #61

Always exclude META-INF/versions/** for library jars.

Will try a different approach after feedback from @FibreFoX


[Crosswalk-11][usecase-wrt][xwalk-3595]Add test for ChromeProtocol

Impacted TCs num(approved): New 1, Update 0, Delete 0
Unit test Platform: Android
Android test result summary: Pass 0, Fail 1, Block 0

Fail BugId: xwalk-3594

LGTM


Drop X- prefix from X-ClickHouse-Progress header

We should drop X- prefix from X-ClickHouse-Progress header based on IETF RFC https://tools.ietf.org/html/rfc6648
The document suggests
   Creators of new parameters to be used in the context of application
   protocols:

   1.  SHOULD assume that all parameters they create might become
       standardized, public, commonly deployed, or usable across
       multiple implementations.

   2.  SHOULD employ meaningful parameter names that they have reason to
       believe are currently unused.

   3.  SHOULD NOT prefix their parameter names with "X-" or similar
       constructs.

I propose simply ClickHouse-Progress

Avoiding X- prefixes is just a 'best practice' / 'recommendation', not a hard rule.
Changing is a bad idea, as will broke backward compatibility. But it's easy to make it configurable.
Generally those header are kinda controversial : streaming headers is not something normal for HTTP exchange, and usually you need to hack your HTTP client to make the steaming read of HTTP headers work. Even poco was hacked to make it possible to send them in steaming mode.
https://github.com/yandex/ClickHouse/blob/0eed697623afd251c1908073c4a2850a9bfc9cdc/dbms/src/IO/WriteBufferFromHTTPServerResponse.cpp#L168-L170
So if you are coding ClickHouse client in multiprocess / multithread environment it's much clearer just to open one more connection and query SELECT * FROM system.processes WHERE query_id = xxx; with any suitable tempo.

Sure but we should follow best practices. Ofc it's a BC break tho. Can be taken care of with version IMO.
About the hacking, yea. I had to bend Guzzle php as well but that's not relevant :)

@filimonov Maybe we can also add a header with query_id.
It will be useful if the user has not provided their own query_id with query.

@simPod I see that naming headers with X- prefix is common practice.
Example: S3 API
https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonRequestHeaders.html
Maybe we simply should not make this changes right now.

We can change it without any compatibility configuration settings. I think, this is Ok in this case.

But we also have X-ClickHouse-User, X-ClickHouse-Key, X-ClickHouse-Quota.
And I cannot change this headers, it will be more harmful than X-ClickHouse-Progress.

Adding a configuration option for HTTP headers prefix (X-ClickHouse-) is Ok, but looks like overkill, because we will have to keep the default with X and almost nobody will have any reson to change it.

Yes, thats definitely overkill. I guess it's only this or that, not both. Decision is yours.


added invite command and event

An example plugin using the invite command and event:
# -*- coding: utf-8 -*-

import irc3
from irc3 import rfc
from irc3.plugins.command import command

@irc3.plugin
class Test:

    requires = [
        'irc3.plugins.core',
        'irc3.plugins.command',
    ]

    def __init__(self, bot):
        self.bot = bot
        self.log = self.bot.log

    @irc3.event(rfc.INVITE)
    def on_invite(self, mask, channel):
        self.bot.join(channel)
        self.bot.loop.call_later(2, self.bot.privmsg, channel, "Thanks %s !" % mask.nick)

    @command
    def invite(self, mask, target, args):
        """
        Invite a user to the current channel

        %%invite <nick>
        """
        self.bot.invite(args['<nick>'], target)

Coverage decreased (-0.04%) to 99.21% when pulling f0a003d2d382e89cf57a9ac7485cf49ddd0a2db3 on metathink:master into f1d5aace975bf26eaad68d148a00eb3cbf13e596 on gawel:master.

Coverage decreased (-0.04%) to 99.21% when pulling f0a003d2d382e89cf57a9ac7485cf49ddd0a2db3 on metathink:master into f1d5aace975bf26eaad68d148a00eb3cbf13e596 on gawel:master.


Support one_of for go_to_place

Hi @mxgrey is this meant to superseed https://github.com/open-rmf/rmf_demos/pull/198?

Thanks for pointing that out, I hadn't noticed it. But I do think the changes in this PR make more sense since it involves less code duplication. We already have a distinction between dispatch_patrol and dispatch_go_to_place so I think lumping the "choose nearest" feature into the latter makes sense.

Sounds good. Thanks for clarifying.


Helmfile doesnt error if helm-secrets fail

I noticed that helmfile doesnt error if there is a problem with helm-secrets decryption.
By mistake, new CI didnt have the plugin installed at all but helmfile still showed
Decrypting secret /...../secrets.yaml
Decrypting /...../secrets.yaml

Still, if plugin is installed, but decryption fails for a reason (e.g. not allowed to decrypt), helmfile will still show the same output.
Took me a while to figure out why it showed secrets in diff/sync locally but not in CI.
It would be great if helmfile would error or at least warn in such cases !

@philicious Hey! Thanks for reporting.
Just curious, but does helm secrets exit with non-zero status in that case? All Helmfile does is calling helm secrets and seeing the exit status to decide if it failed or not. So if it's the issue in helm secrets, I'm not sure how this can be resolved on helmfile side.

here are logs of  the scenario where I found the problem:

helm secrets plugin is not even installed but helmfile diffs or syncs the release with exit code 0 = all good

139699d43dbe:~/project# helmfile -f deploy/helmfile.yaml --namespace backend --environment $STAGE diff
Decrypting secret /root/project/deploy/staging/secrets.yaml
Adding repo bahnx https://xxx.github.io/helm/
"xxx" has been added to your repositories
...
...
139699d43dbe:~/project# echo $?
0

helm secrets by now installed but authentication with the KMS backend hasnt happened and decryption obviously fails then.
you can see, that it now prints a second Decrypting.. line, which likely is the piped output of helm-secrets plugin while the first line is from helmfile, just before calling helm secrets dec.
but still, helmfile exits with 0.

139699d43dbe:~/project# helmfile -f deploy/helmfile.yaml --namespace backend --environment $STAGE diff
Decrypting secret /root/project/deploy/staging/secrets.yaml
Decrypting /root/project/deploy/staging/secrets.yaml

Adding repo bahnx https://xxx.github.io/helm/
"xxx" has been added to your repositories
...
...
139699d43dbe:~/project# echo $?
0

if I then try to decrypt with helm secrets, I do get a bad exit code.
139699d43dbe:~/project# helm tiller run -- helm secrets dec deploy/staging/secrets.yaml
Installed Helm version v2.15.2
Installed Tiller version v2.15.2
Helm and Tiller are the same version!
Starting Tiller...
Tiller namespace: kube-system
Running: helm secrets dec deploy/staging/secrets.yaml

Decrypting deploy/staging/secrets.yaml
Failed to get the data key required to decrypt the SOPS file.

Group 0: FAILED
  projects/xxx/locations/global/keyRings/xxx/cryptoKeys/team-xxx: FAILED
    - | Cannot create GCP KMS service: google: could not find
      | default credentials. See
      | https://developers.google.com/accounts/docs/application-default-credentials
      | for more information.

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.
Error: plugin "secrets" exited with error
Stopping Tiller...
Error: plugin "tiller" exited with error
139699d43dbe:~/project# echo $?
1

as helmfile happily exited, it took me a little while to figure out I missed helm-secrets in this new CI setup and that KMS auth hadnt been properly initialized. I only saw CI being green, logs looked good, but for unknown reason the secrets werent deployed ?! then I debugged it by running helm secrets decmanually and then realized what was going on

@mumoshu any update on this ? we just had another encounter of this bug and debugging can be really annoying if there is no error shown

@philicious Unforutnately, I can't reproduce this... Would you mind sharing the version number of your helmfile?
Also, some debug logs obtained by running helmfile --log-level=debug YOURCMD would be helpful

With helmfile v0.118.7, this is what I get:
$ helm version -c
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}

$ helmfile template
Fetching incubator/raw
Decrypting secret /path/to/helmfile/issue1163/secret.enc.yaml
Decrypting /path/to/helmfile/issue1163/secret.enc.yaml

in ./helmfile.yaml: helm exited with status 1:
  Failed to get the data key required to decrypt the SOPS file.

  Group 0: FAILED
    : FAILED
      - | Error creating AWS session: No valid ARN found in ""

  Recovery failed because no master key was able to decrypt the file. In
  order for SOPS to recover the file, at least one key has to be successful,
  but none were.
  Error: plugin "secrets" exited with error

$ echo $?
1

I am seeing this again on a new macbook:
# helmfile version v0.119.0

Decrypting secret /Users/xx/git/helm/charts/rabbitmq/staging/secrets.yaml
Decrypting /Users/xx/git/helm/charts/rabbitmq/staging/secrets.yaml

in ./xxx.yaml: in .helmfiles[4]: in rabbitmq/helmfile.yaml: error during helmfile.yaml.part.0 parsing: template: stringTemplate:12:38: executing "stringTemplate" at <.Values.managementPassword>: map has no entry for key "managementPassword"

the helmfile doesnt forward the helm-secrets error but only complains about the secret values then not being present.
doing a helm tiller run -- helm secrets dec rabbitmq/staging/secrets.yaml does show me the error.
however helmfile exits with bad exit code at least ! my initial report was with v0.93.2 and that exited with 0 = all good
so now it would be great if helmfile would also pipe the error of helm-secrets so its more obvious what the problem might be

Same here with version v0.134.0


Getting the "SCTP could not connect: Operation timed out" Error

Hi
I'm following your tutorial for the Open5gs and UERANSIM here  with all default values.. (should I edit any values?)
I have a 2 nodes K8s deployment with enough resources..
I'm using NFS provider for the PV/PVCs of the MongoDB.. PVC is Bound and consumed by MongoDB..
For some reason, the  SCTP connection is not established ..
All Pods are Running and looking healthy..
kg po
NAME                                              READY   STATUS    RESTARTS      AGE
nfs-subdir-external-provisioner-ff8fdc59b-rvzd9   1/1     Running   0             37m
open5gs-amf-74867f4d79-rgmkm                      1/1     Running   0             31m
open5gs-ausf-6f7b99444d-jp89j                     1/1     Running   0             31m
open5gs-bsf-78cbddcf6d-kstb2                      1/1     Running   0             31m
open5gs-mongodb-76d8dfbbdb-fzzqk                  1/1     Running   0             31m
open5gs-nrf-5f58b84585-wlbs6                      1/1     Running   0             31m
open5gs-nssf-8676d9bc7b-9qj28                     1/1     Running   0             31m
open5gs-pcf-655ff4967f-pvc5g                      1/1     Running   4 (27m ago)   31m
open5gs-populate-578dd7d4d8-sc9zg                 1/1     Running   0             31m
open5gs-smf-7f864d7d99-g4vhc                      1/1     Running   0             31m
open5gs-udm-7cf88b7c58-zmdj5                      1/1     Running   0             31m
open5gs-udr-6c96f5d447-9jkfk                      1/1     Running   5 (28m ago)   31m
open5gs-upf-fcc6fcd5c-tzd8x                       1/1     Running   0             31m
open5gs-webui-567c65bc7b-n566b                    1/1     Running   0             31m
ueransim-gnb-7d8867667f-4d42f                     1/1     Running   0             25m
ueransim-gnb-ues-6487c85db9-5fhcv                 1/1     Running   0             25m

Here are the logs from different CNFs
UE-RANSIM gNB
kubectl logs deployment/ueransim-gnb -f
N2_BIND_IP: <IP_ADDRESS>
N3_BIND_IP: <IP_ADDRESS>
RADIO_BIND_IP: <IP_ADDRESS>
AMF_IP: <IP_ADDRESS>
Launching gnb: nr-gnb -c gnb.yaml
UERANSIM v3.2.6
[2023-01-21 21:32:40.760] [sctp] [info] Trying to establish SCTP connection... (<IP_ADDRESS>:38412)
[2023-01-21 21:32:41.236] [rrc] [debug] UE[1] new signal detected
[2023-01-21 21:32:41.240] [rrc] [debug] UE[2] new signal detected
[2023-01-21 21:36:03.518] [sctp] [error] Connecting to <IP_ADDRESS>:38412 failed. SCTP could not connect: Operation timed out

SMF
kubectl logs deployment/open5gs-smf -f
Open5GS daemon v2.4.11

01/21 21:29:13.000: [app] INFO: Configuration: '/opt/open5gs/etc/open5gs/smf.yaml' (../lib/app/ogs-init.c:126)
01/21 21:29:13.040: [metrics] INFO: Prometheus mhd_server() [<IP_ADDRESS>]:9090 (../lib/metrics/prometheus/context.c:320)
01/21 21:29:13.040: [smf] WARNING: No diameter configuration (../src/smf/fd-path.c:30)
01/21 21:29:13.040: [gtp] INFO: gtp_server() [<IP_ADDRESS>]:2123 (../lib/gtp/path.c:30)
01/21 21:29:13.040: [gtp] INFO: gtp_server() [<IP_ADDRESS>]:2152 (../lib/gtp/path.c:30)
01/21 21:29:13.040: [pfcp] INFO: pfcp_server() [<IP_ADDRESS>]:8805 (../lib/pfcp/path.c:30)
01/21 21:29:13.040: [pfcp] INFO: ogs_pfcp_connect() [<IP_ADDRESS>]:8805 (../lib/pfcp/path.c:61)
01/21 21:29:13.041: [sbi] INFO: NF Service [nsmf-pdusession] (../lib/sbi/context.c:1400)
01/21 21:29:13.041: [sbi] INFO: nghttp2_server() [<IP_ADDRESS>]:7777 (../lib/sbi/nghttp2-server.c:150)
01/21 21:29:13.042: [app] INFO: SMF initialize...done (../src/smf/app.c:31)
01/21 21:29:20.557: [pfcp] WARNING: [1] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:29:24.044: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:29:24.044: [smf] WARNING: client_cb() failed [-3] (../src/smf/sbi-path.c:55)
01/21 21:29:24.044: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:29:24.045: [sbi] WARNING: [a647a002-99d2-41ed-a156-4373f5fe4ca2] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:29:24.046: [sbi] INFO: [a647a002-99d2-41ed-a156-4373f5fe4ca2] NF registered [Heartbeat:10s] (../lib/sbi/nf-sm.c:222)
01/21 21:29:31.436: [sbi] INFO: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:29:31.436: [sbi] INFO: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:31.553: [pfcp] WARNING: [2] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:29:35.046: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:29:42.558: [pfcp] WARNING: [3] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:29:46.053: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:29:53.557: [pfcp] WARNING: [4] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:29:57.056: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:04.563: [pfcp] WARNING: [5] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:30:08.059: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:15.579: [pfcp] WARNING: [6] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:30:19.063: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:26.577: [pfcp] WARNING: [7] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:30:30.068: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:37.580: [pfcp] WARNING: [8] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:30:41.069: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:48.577: [pfcp] WARNING: [9] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:30:52.071: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:30:59.578: [pfcp] WARNING: [10] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:31:03.097: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:31:10.647: [pfcp] WARNING: [11] LOCAL  No Reponse. Give up! for step 1 type 5 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:31:12.837: [pfcp] INFO: ogs_pfcp_connect() [<IP_ADDRESS>]:8805 (../lib/pfcp/path.c:61)
01/21 21:31:12.838: [smf] INFO: PFCP associated [<IP_ADDRESS>]:8805 (../src/smf/pfcp-sm.c:174)
01/21 21:31:14.108: [smf] WARNING: Retry to association with peer [<IP_ADDRESS>]:8805 failed (../src/smf/pfcp-sm.c:107)
01/21 21:31:14.110: [smf] INFO: PFCP associated [<IP_ADDRESS>]:8805 (../src/smf/pfcp-sm.c:174)
01/21 21:31:15.171: [sbi] INFO: [ef12ed46-99d2-41ed-97eb-1595bb41cf90] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:31:15.172: [sbi] INFO: [ef12ed46-99d2-41ed-97eb-1595bb41cf90] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:31:23.840: [pfcp] ERROR: invalid step[0] type[2] (../lib/pfcp/xact.c:432)
01/21 21:31:23.840: [pfcp] ERROR: ogs_pfcp_xact_update_rx() failed (../lib/pfcp/xact.c:708)
01/21 21:31:26.343: [pfcp] ERROR: invalid step[0] type[2] (../lib/pfcp/xact.c:432)
01/21 21:31:26.343: [pfcp] ERROR: ogs_pfcp_xact_update_rx() failed (../lib/pfcp/xact.c:708)
01/21 21:31:28.876: [pfcp] ERROR: invalid step[0] type[2] (../lib/pfcp/xact.c:432)
01/21 21:31:28.876: [pfcp] ERROR: ogs_pfcp_xact_update_rx() failed (../lib/pfcp/xact.c:708)
01/21 21:31:31.376: [pfcp] WARNING: [13] LOCAL  No Reponse. Give up! for step 1 type 1 peer [<IP_ADDRESS>]:8805 (../lib/pfcp/xact.c:613)
01/21 21:31:31.376: [smf] WARNING: No Heartbeat from UPF [<IP_ADDRESS>]:8805 (../src/smf/pfcp-sm.c:316)
01/21 21:31:31.376: [smf] INFO: PFCP de-associated [<IP_ADDRESS>]:8805 (../src/smf/pfcp-sm.c:181)

AMF
kubectl logs deployment/open5gs-amf -f
Open5GS daemon v2.4.11

01/21 21:27:42.971: [app] INFO: Configuration: '/opt/open5gs/etc/open5gs/amf.yaml' (../lib/app/ogs-init.c:126)
01/21 21:27:42.983: [metrics] INFO: Prometheus mhd_server() [<IP_ADDRESS>]:9090 (../lib/metrics/prometheus/context.c:320)
01/21 21:27:42.984: [sbi] INFO: NF Service [namf-comm] (../lib/sbi/context.c:1400)
01/21 21:27:42.984: [sbi] INFO: nghttp2_server() [<IP_ADDRESS>]:7777 (../lib/sbi/nghttp2-server.c:150)
01/21 21:27:43.002: [amf] INFO: ngap_server() [<IP_ADDRESS>]:38412 (../src/amf/ngap-sctp.c:61)
01/21 21:27:43.002: [sctp] INFO: AMF initialize...done (../src/amf/app.c:33)
01/21 21:27:53.985: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:27:53.985: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:27:53.985: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:28:04.997: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:28:04.997: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:28:04.997: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:28:16.001: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:28:16.001: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:28:16.001: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:28:27.002: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:28:27.002: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:28:27.002: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:28:38.002: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:28:38.002: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:28:38.002: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:28:49.003: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:28:49.003: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:28:49.003: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:29:00.010: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:29:00.010: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:29:00.010: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:29:11.012: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:29:11.012: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:29:11.012: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:29:22.062: [sbi] ERROR: Connection timer expired (../lib/sbi/client.c:495)
01/21 21:29:22.062: [amf] WARNING: client_cb() failed [-3] (../src/amf/sbi-path.c:56)
01/21 21:29:22.063: [sbi] WARNING: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] Retry to registration with NRF (../lib/sbi/nf-sm.c:182)
01/21 21:29:22.065: [sbi] INFO: [709b5c00-99d2-41ed-a70a-c14fd2ad81ed] NF registered [Heartbeat:10s] (../lib/sbi/nf-sm.c:222)
01/21 21:29:22.367: [sbi] INFO: [abd79bc6-99d2-41ed-bb81-b73c88955538] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:29:22.367: [sbi] INFO: [abd79bc6-99d2-41ed-bb81-b73c88955538] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:24.046: [sbi] INFO: [a647a002-99d2-41ed-a156-4373f5fe4ca2] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:29:24.046: [sbi] INFO: [a647a002-99d2-41ed-a156-4373f5fe4ca2] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:31.326: [sbi] INFO: [aa9e70fe-99d2-41ed-a9a7-c532f02dcd23] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:29:31.326: [sbi] INFO: [aa9e70fe-99d2-41ed-a9a7-c532f02dcd23] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:31.434: [sbi] INFO: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:29:31.434: [sbi] INFO: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:31.435: [sbi] WARNING: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF has already been added (../lib/sbi/nnrf-handler.c:632)
01/21 21:29:31.435: [sbi] INFO: [6fdb9438-99d2-41ed-9b16-431c81f1ba2f] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)
01/21 21:29:31.435: [sbi] WARNING: NF EndPoint updated [<IP_ADDRESS>:80] (../lib/sbi/context.c:1572)
01/21 21:29:31.435: [sbi] WARNING: NF EndPoint updated [<IP_ADDRESS>:7777] (../lib/sbi/context.c:1481)
01/21 21:31:15.170: [sbi] INFO: [ef12ed46-99d2-41ed-97eb-1595bb41cf90] (NRF-notify) NF registered (../lib/sbi/nnrf-handler.c:628)
01/21 21:31:15.170: [sbi] INFO: [ef12ed46-99d2-41ed-97eb-1595bb41cf90] (NRF-notify) NF Profile updated (../lib/sbi/nnrf-handler.c:638)

Also, I cant see the uesimtun0 and uesimtun1 interfaces
kubectl exec deployment/ueransim-gnb-ues -ti -- bash

bash-5.1# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
33: eth0@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3a:6e:b0:fb:88:93 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::386e:b0ff:fefb:8893/64 scope link
       valid_lft forever preferred_lft forever

Logs from the ueransim-gnb-ues-6487c85db9-5fhcv Pod
k logs ueransim-gnb-ues-6487c85db9-5fhcv
GNB_IP: <IP_ADDRESS>
Launching ue: nr-ue -c ue.yaml
UERANSIM v3.2.6
[2023-01-21 21:32:40.898] [999700000000002|nas] [info] UE switches to state [MM-DEREGISTERED/PLMN-SEARCH]
[2023-01-21 21:32:40.899] [999700000000001|nas] [info] UE switches to state [MM-DEREGISTERED/PLMN-SEARCH]
[2023-01-21 21:32:40.900] [999700000000001|rrc] [debug] New signal detected for cell[1], total [1] cells in coverage
[2023-01-21 21:32:40.902] [999700000000002|rrc] [debug] New signal detected for cell[1], total [1] cells in coverage
[2023-01-21 21:32:40.905] [999700000000001|nas] [info] Selected plmn[999/70]
[2023-01-21 21:32:40.905] [999700000000001|rrc] [warning] Suitable cell selection failed in [1] cells. [0] out of PLMN, [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:32:40.906] [999700000000001|rrc] [warning] Acceptable cell selection failed in [1] cells. [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:32:40.906] [999700000000001|rrc] [error] Cell selection failure, no suitable or acceptable cell found
[2023-01-21 21:32:40.906] [999700000000002|nas] [info] Selected plmn[999/70]
[2023-01-21 21:32:40.907] [999700000000002|rrc] [warning] Suitable cell selection failed in [1] cells. [0] out of PLMN, [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:32:40.907] [999700000000002|rrc] [warning] Acceptable cell selection failed in [1] cells. [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:32:40.907] [999700000000002|rrc] [error] Cell selection failure, no suitable or acceptable cell found
[2023-01-21 21:32:46.409] [999700000000001|nas] [info] UE switches to state [MM-DEREGISTERED/NO-CELL-AVAILABLE]
[2023-01-21 21:32:46.409] [999700000000002|nas] [info] UE switches to state [MM-DEREGISTERED/NO-CELL-AVAILABLE]
[2023-01-21 21:33:10.941] [999700000000001|rrc] [warning] Suitable cell selection failed in [1] cells. [0] out of PLMN, [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:33:10.941] [999700000000001|rrc] [warning] Acceptable cell selection failed in [1] cells. [0] no SI, [0] reserved, [1] barred, ftai [0]
[2023-01-21 21:33:10.941] [999700000000001|rrc] [error] Cell selection failure, no suitable or acceptable cell found

Hello Sam!
I just tried to replicate the same deployment by following the tutorial you mentioned. It is working perfectly for me: I tried it in our Kubernetes cluster as well as in a local kind cluster.
Can you please give us further details about your Kubernetes environment so we can try to help you??

Hi @mmarquez999
Our lab testing environment consists of :
2 Vagrant boxes (1 Control plane, 1 Worker), both are (generic/ubuntu2004) deployed inside a large VM (Ubunto)..
Ansible is automating the whole deployment via kubeadm + Helm + Cilium CNI (SCTP enabled)..
Kernel Version
Both Vagrant Boxes are
Linux kube1 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Kubernetes Version
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"b46a3f887ca979b1a5d14fd39cb1af43e7e5d12d", GitTreeState:"clean", BuildDate:"2022-12-09T16:23:44Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.5", GitCommit:"804d6167111f6858541cef440ccc53887fbbc96a", GitTreeState:"clean", BuildDate:"2022-12-08T10:08:09Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"}

cilium version
cilium-cli: v0.12.12 compiled with go1.19.4 on linux/amd64
cilium image (default): v1.12.5
cilium image (stable): v1.12.5
cilium image (running): v1.12.5

Hi @sam-sre
Last time I searched about cilium, I found that it does not support SCTP but, thanks to your issue, I can now see that it is a beta feature (https://docs.cilium.io/en/latest/configuration/sctp/#sctp). I don't know if its restrictions affect the connectivity of the deployment. Here you can find more information about it: https://github.com/cilium/cilium/issues/20490
If you can change the CNI and test the deployment, we can be sure that it is Cilium's fault or it is another problem.

Hi @avrodriguezgrad
Correct, Cilium didnt support SCTP before. I used Cilium version: 1.13.0-rc3 for my setup and enabled SCTP..
Can you give it a try with Cilium?
I'll try it out with Calico and post the results here..

Confirming it worked with Calico..
Although Cilium is preferable to investigate security and observability options ..
Waiting for your outcome @avrodriguezgrad ^^

Hi @sam-sre
I could check with Cilium and I could make it work. I followed this tutorial to deploy a kind cluster with Cilium and the version you told me (https://www.bookstack.cn/read/cilium-1.12-en/5be6a00e6ed03350.md), deployed the charts with the tutorial we have and, in the following screenshot, you can see my deployment.

FYI,

I don't know if I can help you in something else.

Hi @avrodriguezgrad
Interesting!
Did you have to pass the --set sctp.enabled=true variable to helm? or did you follow exaclty steps mentioned on your link here

Hi @sam-sre
Yes, I followed exactly the steps of the link I mentioned but, also, I passed the SCTP variable to Helm.

Hi @avrodriguezgrad
I deployed a KinD environment and followed the exact same steps. It didnt work.
I think it is something related to the cgroup versions..
The below commands gave same value which they should'nt
sudo ls -al /proc/$(docker inspect -f '{{.State.Pid}}' kind-control-plane)/ns/cgroup
sudo ls -al /proc/self/ns/cgroup

I'll investigate more but it is definitely not on the application side .. so thanks very much for the help..


C++ test Core dump DROPOUT_PERF.TimingGPU

http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/master/399/pipeline
Timing: 50 iterations of 10 calls, shape = [50,3,18,32] = 86,400 items

Dropout Operator CPU:  Timing [Forward] 28.45100 ms, avg: 0.05690 ms X 500 passes

[       OK ] DROPOUT_PERF.TimingCPU (2745 ms)

[ RUN      ] DROPOUT_PERF.TimingGPU

Timing: 50 iterations of 10 calls, shape = [1,1,28,28] = 784 items

terminate called after throwing an instance of 'dmlc::Error'

  what():  [22:22:55] ../mshadow/mshadow/./stream_gpu-inl.h:182: Check failed: e == cudaSuccess CUDA: an illegal memory access was encountered

Stack trace returned 10 entries:

[bt] (0) build/tests/mxnet_unit_tests(dmlc::StackTrace[abi:cxx11]()+0x56) [0xe15776]

[bt] (1) build/tests/mxnet_unit_tests(dmlc::LogMessageFatal::~LogMessageFatal()+0x28) [0xe15d78]

[bt] (2) build/tests/mxnet_unit_tests(void mshadow::DeleteStream<mshadow::gpu>(mshadow::Stream<mshadow::gpu>*)+0xb9) [0xe183f9]

[bt] (3) build/tests/mxnet_unit_tests(mxnet::test::op::CoreOpExecutor<float, float>::~CoreOpExecutor()+0x151) [0xe5f321]

[bt] (4) build/tests/mxnet_unit_tests(std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()+0x46) [0xe1b316]

[bt] (5) build/tests/mxnet_unit_tests() [0xf0435e]

[bt] (6) build/tests/mxnet_unit_tests(DROPOUT_PERF_TimingGPU_Test::TestBody()+0x5e1) [0xf06401]

[bt] (7) build/tests/mxnet_unit_tests(void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)+0x43) [0xf36f03]

[bt] (8) build/tests/mxnet_unit_tests(testing::Test::Run()+0xba) [0xf27f3a]

[bt] (9) build/tests/mxnet_unit_tests(testing::TestInfo::Run()+0x118) [0xf28088]

/workspace/tests/ci_build/with_the_same_user: line 47: 83345 Aborted                 (core dumped) sudo -u "#${CI_BUILD_UID}" --preserve-env "LD_LIBRARY_PATH=${LD_LIBRARY_PATH}" "HOME=${CI_BUILD_HOME}" ${COMMAND[@]}

script returned exit code 134

then it's not "flaky", right?  I mean, it's never broken before, right?  I also noticed it breaking in another build today.
I wonder if it ever broke pre-mkldnn merge?

It's flaky because otherwise it would have been reported during PR stage.
Well the number of test failures drastically increased since the mkldnn merge. But that's why we merged it, right? To get some data early on.

just a side note, should we add try catch around for TESTs and fail so that consecutive tests continue to execute ?

No, this would waste too many resources. Generally, multiple failures can be fixed by one change. If we wouldn't follow fail-fast, a lot of time would be wasted. Considering the fact that PRs should be small, the chance of multiple independent bugs causing multiple test failures is quite small compared to the number of total tests executed within every PR.
The right approach is to fix one test failure, create a new commit and then fix the next test failure. While this actually sounds pretty wasteful as well, past experience has shown that this is rarely required.
Additionally, we're currently working on something that allows you to run tests locally in exactly the same way the CI does. This will allow you to test yourself before pushing it to the CI.

@marcoabreu  I ran this test ~1000 times, couldnt replicate the failure. Can we close this issue ?

@spidyDev @marcoabreu I think there were some crossed wires on this one.  This test is actually enabled.  Was it at one time disabled?

@spidyDev agree.  @marcoabreu think we could close this one?

Sure, thanks for following up. I think this was due to the MKLDNN change.

The issue is not related to C++ API. Removing the C++ label.
@mxnet-label-bot remove [C++]


Strange interaction between framing, preconditions, and conditionals

test4 fails and the only difference with test2 is that it contains an irrelevant framed assertion ff xx
module MemCpy
open Steel.Memory
open Steel.Effect
open Steel.Effect.Atomic
module U32 = FStar.UInt32

#push-options "--ide_id_info_off"
#push-options "--max_fuel 0 --max_ifuel 0"

let fst = fst
let snd = snd
assume
val array (t:Type0) : Type0
let contents (t:Type0) = Seq.seq t
let length #t (c:contents t) = Seq.length c
assume
val is_array (#t:_) (x:array t) (c:contents t) : slprop u#1

assume
val split (#t:Type) (#r:contents t) (a:array t) (i:U32.t { U32.v i <= length r})
  : SteelT (array t & array t)
           (is_array a r)
           (fun lr ->
              let s = Seq.split r (U32.v i) in
              is_array (fst lr) (fst s) `star` is_array (snd lr) (snd s))

let test1 (a:Type) (len:U32.t { U32.v len > 0 })
          (v0:contents a { length v0 == U32.v len })
          (src:array a)
    : SteelT unit
      (is_array src v0)
      (fun _ -> emp)
    = let x = split src 1ul in
      sladmit()

let test2 (a:Type) (len:U32.t)
          (v0:contents a { length v0 == U32.v len })
          (src:array a)
    : SteelT unit
      (is_array src v0)
      (fun _ -> emp)
    = if len = 0ul
      then (noop(); sladmit())
      else (
        let x = split src 1ul in
        sladmit()
      )

assume
val t : Type0
assume
val ff (x:t) : slprop u#1

let test3 (a:Type) (len:U32.t { U32.v len > 0 })
          (v0:contents a { length v0 == U32.v len })
          (src:array a)  (xx:t)
    : SteelT unit
      (is_array src v0 `star` ff xx)
      (fun _ -> emp)
    = let x = split src 1ul in
      sladmit()

let test4 (a:Type) (len:U32.t)
          (v0:contents a { length v0 == U32.v len })
          (src:array a) (xx:t)
    : SteelT unit
      (is_array src v0 `star` ff xx)
      (fun _ -> emp)
    = if len = 0ul
      then (noop(); sladmit())
      else (let x = split src 1ul in
            sladmit())

Minimizing further, the following test4 fails:
let test4 (a:Type) (len:U32.t)
          (v0:contents a { length v0 == U32.v len })
          (src:array a) (xx:t)
    : SteelT unit
      (is_array src v0 `star` ff xx)
      (fun _ -> emp)
    = assume (length v0 > 0);
      let x = split src 1ul in
      sladmit()

I am unable to verify even test2 in the master branch.

Here is a small repro:
module Test

open Steel.Memory
open Steel.Effect
#push-options "--ide_id_info_off"
#push-options "--max_fuel 0 --max_ifuel 0"

assume
val is_elt (_:Seq.seq ℤ & Seq.seq ℤ) : slprop u#1

assume
val split (r:Seq.seq ℤ) (i:ℕ {i ≤ Seq.length r})
  : SteelT unit
           emp
           (λ _ → is_elt (Seq.split r i))

assume val drop (p:slprop u#1) : SteelF unit p (λ _ → emp) (λ _ → ⊤) (λ _ _ _ → ⊤)

let test4 (v0:Seq.seq ℤ)
    : Steel unit
        emp
        (λ _ → emp)
        (λ _ → Seq.length v0 == 2)
        (λ _ _ _ → ⊤)
    = let x = split v0 1 in
      drop (is_elt (Seq.split v0 1))

Move the requires to a refinement on v0, and it works.

This also works:
let test4 (v0:Seq.seq ℤ)
    : Steel unit
        emp
        (λ _ → emp)
        (λ _ → Seq.length v0 == 2)
        (λ _ _ _ → ⊤)
    = let _ : squash (Seq.length v0 == 2) = () in
      let x = split v0 1 in
      drop (is_elt (Seq.split v0 1))

and so does this in the original example:
let test4 (a:Type) (len:U32.t)
          (v0:contents a { length v0 == U32.v len })
          (src:array a) (xx:t)
    : SteelT unit
      (is_array src v0 `star` ff xx)
      (λ _ → emp)
    = if len = 0ul
      then (noop(); sladmit())
      else (let _ : squash (U32.v len > 0) = () in
            let x = split src 1ul in
            sladmit())

We discussed this issue during today's Steel meeting. As mentioned by Aseem, the problem is that the tactic context does not contain the logical context. As such, when some SMT goals for refinements are generated during the tactic run, verification fails because of missing facts. This is why adding a bound squash variable with the right facts is a workaround.
We discussed the following two solutions:
1/ When an SMT goal is generated during the tactic, add it to the equality abduction variable. This will ensure it will have the correct facts in the context, and we already have most of the machinery in place. The problem is that we do not currently have this variable in all separation logic VCs because of limitations in subcomp.
2/ Add a mechanism similar to assert by tactic, (called collect by tactic) to encode SL goals inside the logical context, while deferring them to a tactic.
We agreed to try 1/ first, as 2/ might be a more involved change.


[BUG] Dockerfile build failing

Describe the bug
Dockerfile build failing
To Reproduce
Steps to reproduce the behavior:

docker compose build

Expected behavior
A clear and concise description of what you expected to happen.
Assets
If applicable, add screenshots/videos to help explain your problem.
Desktop (please complete the following information):

OS: macOS 14.2.1 (23C71)

fix PR #253


jest fully ts

fix: eslint
fix: eslint config update
fix: eslint config update packages
fix: ran eslint
fix: jest config + setup in ts

:tada: This PR is included in version 0.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


results on tsplib

hi there, thanks for your contribution on this work, but the results of table 4 can't be reproduced, especially on AM(N=1280), AM(N=5000) and ours(T=3000), are you an co-author or a member of the institution mentioned in the original paper?

Hi, I am not the co-author of this paper but I am also doing research in this filed. May I know more details on what happened when you tried to reproduce table 4?

Hi, I am not the co-author of this paper but I am also doing research in this filed. May I know more details on what happened when you tried to reproduce table 4?

OK thanks again. When I reproduce the results in table 4, the objective values of these instances are quite larger than those reported in this table by a huge margin. The model of AM I used are the pretrained model: tsp_100 epoch-99.pt from Kool's github repository, the model of this paper is the one that I reproduce by your code.

Thanks for the reply. Based on my experience, may I check did you use the following normalization?
data = (coordinates - np.min(coordinates)) / (np.max(coordinates) - np.min(coordinates))
After getting the results, we need to scale back the obj values by multiplying the (np.max(coordinates) - np.min(coordinates)).

Thanks for the reply. Based on my experience, may I check did you use the following normalization?
data = (coordinates - np.min(coordinates)) / (np.max(coordinates) - np.min(coordinates))
After getting the results, we need to scale back the obj values by multiplying the (np.max(coordinates) - np.min(coordinates)).

yes, we did the same normalization but I didn't scale back because I find the AM model is better than paper's model after normalization

Oh, then I am not really sure about what causes such differences here.

Btw, I haven't tried to run this model or AM on TSPLIB but I tried to test the generalization of this model on different sizes (i.e., solve tsp100 with tsp50 model) which was found not good in my opinion.

Btw, I haven't tried to run this model or AM on TSPLIB but I tried to test the generalization of this model on different sizes (i.e., solve tsp100 with tsp50 model) which was found not good in my opinion.

you are right, I hold your opinion

One more question, does or-tools have additional tricks during using? I use the example  version to run thes tsplib but the results are worse than those reported in this paper.

One more question, does or-tools have additional tricks during using? I use the example  version to run thes tsplib instances but the results are worse than those reported in this paper.

Hmmm, I think the default setting should work well. Maybe you should check the hyper-parameters set for OR-TOOLS (e.g., the number of iterations?).


Memory leak when gateway.connect and gateway.disconnect are called repeatedly

We found memory-leak behavior when we call gateway.connect and gateway.disconnect repeatedly,
though we expected that gateway.disconnect cleans up.
We tried executing the code attached to this issue on the following environments.

We attached the code to this issue for reproduction.
sdk-sample.tar.gz

I can observe similar characteristics over a 5 minute run of your test application, with an initial state of

Memory usage: rss=73707520, heapTotal=54771712, heapUsed=17472296, external=1772632, arrayBuffers=79336

And at the end of the 5 minute run of:

Memory usage: rss=214474752, heapTotal=89112576, heapUsed=40513000, external=6138530, arrayBuffers=4477856

Then after a few seconds pause to give the garbage collector a chance to do some cleanup a final state of:

Memory usage: rss=215228416, heapTotal=56606720, heapUsed=40342008, external=6179602, arrayBuffers=4518768

It would need some profiling of the heap to identify exactly what was using the space and confirm it isn't caused by some other aspect of Node runtime or heap management.
I must point out that creating and discarding large numbers of connections is not good practice. You generally want to keep your Gateway connection around for and use it for all work carried out by a client identity.

One other thing is that the sample client code you posted does not wait for completion of the async connect() call before then going on to call disconnect(). This is incorrect usage but I'm not sure it contributes to the memory behaviour you observe.

I have seen the same behaviour and noticed that the grpc connections remain open both on the client as well as the peer.  Running the same version of the sdk, fabric-peer 2.2.2.

Aside from memory problems, this also causes connections to remain open. This can eventually cause a server to run out of available connections, as also reported here: https://stackoverflow.com/questions/49695485/network-leak-issue-with-event-hub-and-peer-connections-in-fabric-client-node-js
I understand the intention is not to use gateways rapidly, but that should be a performance consideration, and not a reason to leave memory and connections hanging.
Has anyone found a solution to this, other than forcibly restarting the node process the gateway is connecting through?

Any news on this?

I managed to reduce connection leak by doing two things (both):

closing endorsers connections specified in connection profile just after gateway connects
manually closing discovery service connection at the end

It worked in my case (for connection leaks, I didn't check memory leaks), but it was a lot of debugging and experiments. It reduced all connection leaks for successful chaincode invocations, but left some when chaincode invocation failed. Maybe it will help someone with debugging this stuff. I will probably give up and use Fabric Gateway for Fabric 2.4 anyway (https://github.com/hyperledger/fabric-gateway).
await gateway.connect(connProfile);
peerNames.forEach(peerName => {
  // @ts-ignore
  gateway.client.endorsers.get(peerName).disconnect(); // those connections will be replaced by new ones, but there will be no leak
});

const network = await gateway.getNetwork(contractConfig.channelName);
const fabricDiscoveryService = network.discoveryService; // get the reference here, not after calling contract
...
fabricDiscoveryService.close();
gateway.disconnect();

I've experiencing the same issue on Debian11, with fabric node SDK 2.2.15, and fabric 2.4.x. I will attempt the workaround proposed by @dzikowski .

A slight change to connection closing was deliver in the v2.2.17 release, which might help with this issue. The workaround mentioned above does not seem ideal but the handling of connections created during connection profile handling does sound like a good candidate for the problem area - thank you @dzikowski for the investigation.
If you are using (or can use) Fabric v2.4 or later, you should use the Fabric Gateway client API, which has much more efficient connection behaviour. It can use a single gRPC connection (over which you have direct control) for all interactions with Fabric, regardless of the number of client identities you are working with. See the migration guide for details.

I use sdk 2.2.18. Connect the fabric network and submit tens of transactions and then disconnect the network. It also ends with core dumped.
node[30909]: ../src/node_http2.cc:561:static void* node::http2::Http2Session::MemoryAllocatorInfo::H2Realloc(void*, size_t, void*): Assertion `(session->current_nghttp2_memory_) >= (previous_size)' failed.
 1: 0x8fb090 node::Abort() [node]
 2: 0x8fb165  [node]
 3: 0x95ecfa  [node]
 4: 0x1738b28 nghttp2_session_close_stream [node]
 5: 0x173fe8a nghttp2_session_mem_recv [node]
 6: 0x95af67 node::http2::Http2Session::ConsumeHTTP2Data() [node]
 7: 0x95b1ef node::http2::Http2Session::OnStreamRead(long, uv_buf_t const&) [node]
 8: 0xa2cc21 node::TLSWrap::ClearOut() [node]
 9: 0xa2cfc0 node::TLSWrap::OnStreamRead(long, uv_buf_t const&) [node]
10: 0x9d1021  [node]
11: 0xa7d3d9  [node]
12: 0xa7da00  [node]
13: 0xa83b58  [node]
14: 0xa71bbb uv_run [node]
15: 0x905665 node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::string, std::allocator<std::string> > const&, std::vector<std::string, std::allocator<std::string> > const&) [node]
16: 0x90374f node::Start(int, char**) [node]
17: 0x7f121e0e9445 __libc_start_main [/lib64/libc.so.6]
18: 0x8bce95  [node]

I use sdk 2.2.18. Connect the fabric network and submit tens of transactions and then disconnect the network. It also ends with core dumped.

Is this a new problem that worked with previos SDK versions and has just started appearing with v2.2.18? It looks like a physical memory allocation failure in the Node runtime so it might be worth checking the version of Node you are using and also monitor the system memory used and available to the Node process.

Hi,
I originally posted this on the discord server, but I came across this issue which applies to me.
I am using HLF v3.0.0-beta and SmartBFT as consensus.
I see a linear increase in the memory usage of my orderers (all of them not only the leader) until a certain point (between 400 and 750MB, although I don't have an overflow: neither for my entire system nor for the docker containers). The limit of this increase doesn't seem to be the value of memory used but the time after which it stops increasing, because no matter the value it is at, it practically stops increasing after ~10h (x-axis = 20k)
We can clearly see that on the plot I added. Does anyone have any explanations ?

More explanations on the plot itself and my experimentations :
The plot represents the Evolution of memory usage of orderers and peers nodes for 4 different runs that each lasted 15h. (The x-axis is not very clear, but 1 unit corresponds to ~7s which makes the total around 58h = 4x ~15h)
I used multiple channels (5 everytime) for each of my runs, but depending on the run the channels are not updated at the same frequency which would perfectly explain the difference between the 2 orange lines on runs 2 and 4. Each run is actually a repetition (7500x here) of the same actions (some write and reads) and I open a gateway (and close it at the end) for every repetition.
According to what was mentioned in this issue, I believe this could be the problem, but I thought that using the Gateway should fix this so I don't know if there is something I could do (except from resetting the gateway of course : this is maybe doable in my case but would deeply modify my implementation)
In any cases this doesn't explain the increase stopping at x=~20k for every runs I made which are not coherent with a memory leak but maybe there is a link that I am not able to see...

@ConstantRohmer This repository contains the (legacy) SDK for Node.js client applications, and this issue relates to Node.js client application memory usage. For issues relating to the Fabric orderer, you need to use the core Fabric repository.

@ConstantRohmer This repository contains the (legacy) SDK for Node.js client applications, and this issue relates to Node.js client application memory usage. For issues relating to the Fabric orderer, you need to use the core Fabric repository.

Sorry for that, I didn't pay attention to the repo this issue was in.
However now that I know that, the gateway connection opening/closing should not increase the orderer's memory usage but only the peer's usage, so the problem I am experiencing is probably not due to that (at least not only)
I will switch to the correct repo and ask my question again !


New version of htmltest - uses data-proofer-ignore

Add data-proofer-ignore tag to auto-generated sidebars.
Use a version of htmltest which removes child nodes from html nodes with data-proofer-ignore set.
New version of htmltest built from this PR: https://github.com/wjdp/htmltest/pull/188

Looks good to go. The test data get reverted after this is merged to development?

It's already reverted: https://github.com/mendix/docs/pull/4511/commits/ebd8cc3491c4223c500f2f8a5f476a615112d0fb