text:
Problem HTTP Healthcheck protocol when use a SSL Backendset

BUG REPORT
CCM Version: v1.24.0
Environment:

Kubernetes version (use kubectl version): 1.24.1
OS (e.g. from /etc/os-release): Oracle-Linux-7.9-2022.08.29-0
Kernel (e.g. uname -a): 5.4.17-2136.310.7.el7uek.x86_64
Others: Using OCI (Load Balancer)

What happened?
I am trying to deploy a Bitnami Keycloak where this services exposed a HTTPS protocol. I configured my deployment using the OCI Load Balancer with listeners 80 and 443 (with TLS/SSL) and it was created correctly. However, when entering the Keycloak using the 443 port the Load Balancer responds with a 502.
The annotation configs are:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "HTTP"
service.beta.kubernetes.io/oci-load-balancer-tls-secret: keycloak-tls
service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: keycloak-tls

Temporary solution:
I was checking the Load Balancer and I realized that the problem was in the HealthCheck Protocol. By default the protocol with which the HealthCheck is created is of type HTTP and this throws me an error when verifying the instances in port 10256. When I change the protocol to TCP it works correctly and I can access the Keycloak using the 443 of the Load Balance.

Reviewing the code history I have seen that before version 0.12.0 the TCP protocol was specified in case SSL was used in the Backendset. However, after that version it was removed.

The use of TCP was changed as it was a mistake. For Kubernetes managed LBs which use node port, the health check needs to be to the kube-proxy health check port and the health check needs to verify HTTP status code of kube-proxy healthz endpoint. By changing the health check to TCP we are not doing the right health check, it just appears to fix the issue which is actually a limitation from OCI LB side and the fix for which is actively getting worked on. The issue is that OCI LB does a HTTPS health check on the backends if the backendset is SSL enabled. But kube-proxy does not support HTTPS health check as it does not have access to the TLS/SSL certs used by the application.
We will update once the support for point to point SSL is supported by OKE after the OCI LB service supports doing HTTP health check for HTTPS backends.

Ok, thanks for your answer.
In this moment I created manually the LB in my OKE architecture using the TCP Healthcheck and this works perfectly.

If you change the health check to TCP it would not complain, but the health check is not doing the right check. The health check endpoint should be probed for the HTTP status code to determine the health and not just check for a TCP listener on the health check port.

authors: AkarshES GatoSnake

repo: oracle/oci-cloud-controller-manager


text:
While applying grid patches observed the below error.

Hi Everyone,
I am unable to resolve this error while running the playbook and not sure where this group_names needs to be defined. Please help where this variable needs to be defined.
PLAYBOOK: gi-opatch.yml ************************************************************************************************************************************************
1 plays in gi-opatch.yml
ERROR! The field 'hosts' has an invalid value, which includes an undefined variable. The error was: 'group_names' is undefined
The error appears to be in '/home/ansible/ansible-patching/gi-opatch.yml': line 1, column 4, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:

name: Apply patches to GI
^ here

Needs a refactoring of current inventory and playbooks.
This is planned for a later time.

The example inventory from ansible-oracle does not have an example with patching.
Oracle changed the policy for downloading patches from support.oracle.com. Patches older then 1 year require a special password, which is changed every week.
The reason is: Customer should not install old patches.
I have to change the example inventory in short intervals and we need a download mechanism for download + unzip of RUs.
This is to difficult at the moment. That's why ansible-oracle has no patching in the example Inventory at the moment.
Please use the extended example from ansible-oracle-inventory.
https://github.com/opitzconsulting/ansible-oracle-inventory

source: gharchive/issue

authors: Rendanic jamespackiam

repo: oravirt/ansible-oracle

license: mit

license_type: permissive

license_source: bigquery


text:
Femto Bolt相机2-3分钟后停止工作

运行pyorbbecsdk功能包中的example/color_viewer.py
无论是单开color通道读取rgb还是单开depth通道读取深度都会在一段时间（2-3分钟）卡死，导致color_frame = frames.get_color_frame()读取到的是None，随后frames: FrameSet = pipeline.wait_for_frames(100)也读取为None，增加了wait的时间到1000，增加了buffur的容量，更换了usb数据线，重启都试过了，还是会出现一样的问题。

是电脑还是开发板？

是电脑还是开发板？

使用的电脑， ubuntu20.04

repo: orbbec/pyorbbecsdk

license_source: github-api


text:
How to solve "Coulde not open "{DeviceCode}" : Failed Open the device" problem?

{log}
342584897 VERBOSE    Initialize: Already initialized
342584984 VERBOSE    Trying to open device by URI '2bc5/0403@3/25'
342586178 VERBOSE    Initializing device sensor...
342586356 VERBOSE    Configuring module 'Device' from section 'Device' in file '/home/bp/catkin_ws/src/ros_astra_camera-master/include/openni2_redist/x64/OpenNI2/Drivers/orbbec.ini'...
342586531 INFO       Setting Device.UsbInterface to 2...
342586574 INFO       Device.UsbInterface value did not change.
342587270 INFO       Module 'Device' configuration was loaded from file.
342587322 VERBOSE    Connecting to USB device...
342587330 VERBOSE    Trying to open sensor '2bc5/0403@3/25'...
342587385 VERBOSE    Shutting down USB depth read thread...
342587430 VERBOSE    Shutting down USB image read thread...
342587439 VERBOSE    Device closed successfully
342587476 VERBOSE    Shutting down Scheduler thread...
[ INFO] [1590374125.244976308]: No matching device found.... waiting for devices. Reason: astra_wrapper::AstraDevice::AstraDevice(const string&) @ /home/bp/catkin_ws/src/ros_astra_camera-master/src/astra_device.cpp @ 79 : Device open failed
Could not open "2bc5/0403@3/25": Failed to open the USB device!

I am also facing similar problem.

authors: Kidous qintxwd


text:
preparations for js-ipfs 0.29.0

Similar to https://github.com/orbitdb/ipfs-log/issues/124. Here I was less lucky, some tests failed with always the same error, example bellow:
 6) orbit-db - Automatic Replication (js-ipfs)
       automatic replication exchanges the correct heads:

      Uncaught AssertionError [ERR_ASSERTION]: must be a valid cid
      + expected - actual

      -false
      +true

Thanks @diasdavid for keeping us up to date! ❤
Will try to work the new release into OrbitDB asap. Any ideas what the ^ must be a valid cid comes from? PubSub (as mentioned in https://github.com/orbitdb/ipfs-log/issues/124)?

It doesn't look like orbit-db or ipfs-log has js-ipfs-block in its dependency tree though.

My recommendation is to update all deps.

authors: diasdavid haadcode mistakia

repo: orbitdb/orbit-db

license: MIT


text:
re publish access events on different channels

provide means to publish the events in different queue based systems (in alternative), such as:

AMQP
MQTT
NGSI-V2

Originally posted by @chicco785 in https://github.com/orchestracities/anubis/issues/17#issuecomment-1099570261

each data controller should be able to define it's one channel to received notifications of accesses to it's resources

repo: orchestracities/anubis


text:
cargo fmt

proposing to switch to 2 spaces and using leptosfmt for the html inside view! {} macro. thoughts?

Good idea! In addition few suggestions:

Use something like rusty-hook to run rustfmt before commit something.
Add leptosfmt as dev-dep to Cargo.toml (not sure if this is the common way) or add it to just install script. Same with rustfmt?

good points. added rusty-hook as well. ready for review

source: gharchive/pull-request

authors: FelixWeis sectore

repo: ordilabs/live


text:
Feature request: Ability to put extra information on a microservice

It would be great to have the ability to add some extra information on the microservices nodes in the dashboard.
One of the elements we would like to visualize on the microservice dashboard is the max load (#request/hour) a microservice can handle (for example due to backend limitations) .

Would this load be dynamic or a fixed value you define?
Currently you can add such information to nodes, although only to virtual nodes.

Your suggestion advocates for adjusting retrieved nodes (non-virtuals) as well.
We'll incorporate this hopefully in our first release (planned 28th of July).
Error gathering is also ongoing by the way, as you can see in the screenshot below:

authors: andreasevers thomasiderycke

repo: ordina-jworks/microservices-dashboard


text:
Set z-index to highest possible value

close #377

@orestbida for what it's worth, I actually think this is a good example for something that should be configurable since the z-index order is so different for each app. Additionally I don't like customizing it via CSS since somehow the CSS api feels less stable than JS and this would be the only thing I would need to customize the CSS for.

authors: orestbida theflow

repo: orestbida/cookieconsent


text:
Prettify md/scss and update dependencies

I ran npm i && npm run format and npm run upgrade to fix linting and update a few deps.

@rtsisyk did it break po4a?
@meenbeese did you test po4a localization tool? What caused so many format changes? Is it possible to avoid replacement somehow?

did you test po4a localization tool? What caused so many format changes? Is it possible to avoid replacement somehow?

No, how can I test that? I just did the prettify as suggested.
I don't see why we should try to avoid the replacements.

I tried with the latest version from master but it still produces the same result. And I didn't set up any different config for the formatter either, just using the default one.
As this is not especially important, I can just close the PR and focus on more important issues that need to be resolved. The only formatting critical for me is this in the main.css:
@media (width <= 768) {

As zola serve refuses to compile for me when it is as such. I have to change it to:
@media (max-width: 768) {

Which I had previously did in my last merged PR but it was reverted when you ran your formatter. How can we solve this?

Please avoid merge commits and always use rebase. You may need to practice a bit to better understand it. It is required in our git workflows.
I don't have any build issues with zola related to scss. What is your zola version? Could it be that you have some conflicting global npm packages installed that influence the behavior of the formatter and scss transpiler?

Please avoid merge commits and always use rebase. You may need to practice a bit to better understand it. It is required in our git workflows.

Thanks, I will try to explore rebase a bit more.

I don't have any build issues with zola related to scss. What is your zola version?

My zola version is 0.16.1

Could it be that you have some conflicting global npm packages installed that influence the behavior of the formatter and scss transpiler?

I do have Prettier installed which may be the culprit behind the formatting changes but that doesn't explain the scss compiling error.

✗ zola --version
zola 0.17.2

Please install the latest zola version.

I can confirm that updating the zola version to 0.17.2 solved the error completely. Maybe we should document this in the README? I was planning on improving the README anyway sometime.

You can clarify there that we're using the latest zola.

authors: biodranik meenbeese


text:
Have a class macro for traffic control

Stoplight is good at wrapping whole Rails controllers actions, though sometimes you just want a small piece of the action to be controlled - like integrating with a remote service from which you can recover with good user experience when the service fails. A good example - lets say you want to pull a user's data from a few services. If one of them doesn't respond it's still OK to show the partial data and say "Sorry, this one is out".
For such a use case I'd love to have a class macro that has sensible defaults I can override easily. An example:
class RemoteService
  include Stoplight::TrafficControl

  def remote_call
    # whatever
  end

  controlls_traffic_on :remote_call,
    allow_errors: [SomeError], # optional
    threshold: 10, # optional
    timeout: 120, # optional
    name: 'ServiceName', # optional
    on_red: :do_something_different #optional

  def do_something_different
    # whatever
  end
end

I'd love to open a PR for this. Just wanted to hear what you think.

This is an interesting idea. Do you think that the existing Stoplight method is not well suited to solving this problem? For example, I would wrap remote_call in a stoplight like so:
class RemoteService
  def remote_call
    Stoplight('ServiceName') { remote_call_without_stoplight }
      .with_allowed_errors([SomeError]) # optional
      .with_threshold(10) # optional
      .with_timeout(120) # optional
      .with_fallback { |e| do_something_different } # optional
      .run
  end

  def remote_call_without_stoplight
    # whatever
  end

  def do_something_different
    # whatever
  end
end

The controls_traffic_on method you are describing would basically be calling Stoplight like that, plus aliasing a few methods.

What do you think, @s1mplex? Does the existing Stoplight method work for you?

@tfausak Yeah it works! What I wanted to achieve was to simplify settings things up even more but maybe that'd overcomplicate things too much rather than making it easier.

In my opinion, it would add too much complexity. I prefer being explicit, especially when it isn't that much more verbose.
Thank you for the suggestion, though!

repo: orgsync/stoplight


text:
Provide lock free version of hash index

We should use these papers as base http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/SplitOrderedLists.pdf http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf
Do not forget that we use JNA and support platforms beyond Oracle JDK which means that we should work with native memory barriers like this one http://trac.mcs.anl.gov/projects/openpa it has very good multiplatform support but robustness should be investigated.

Not relevant any more

Can you give a quick explanation why? Or, maybe just a reference to the change that makes it irrelevant?
Scott

Hi @smolinari
We are working now on new tx model which will be based on locks with page granularity.
But in some cases will allow to hold write-write , read-write, write-read locks by different threads at the same time.
It will allow us to automatically convert all data structures to their mt version with low level of contention between threads.
We tried to base our tx mechanics on CAS model, but in case of high load it requires a lot of retries and as result system SLA becomes unpredictable.
After finishing of page lock based MT model we will concentrate on algorithms which oriented on NUMA architecture, we think it will bring even more performance gains than additional improvements in MT scalability.

Although most of that flew above my head, it sounds good. Thank you for the explanation.
Scott

@smolinari well main idea is that in case of high load, cas or lock-free protocols require many retries and amount of such retries is not predictable and as result client SLA also becomes unpredictable. So we use approach when we use locks but with very low granularity to avoid contention of threads.

What does SLA mean?
Scott

service level agreement, in other words distribution of latency of operations.

I thought that is what you meant, I just wasn't sure how an SLA could relate to multi-threading. But, I guess, if the database is supposed to meet certain specs as a purchase point and those specs are guaranteed, then I guess I can understand it. It isn't really SLA's though. It is more like fulfilling contractual obligations.
Scott

authors: laa smolinari

repo: orientechnologies/orientdb


text:
Bitwise Operators

Hi,
It would be great to have support for bitwise operators.
In the SQL parser syntax page it seems that there is plan for it already  :
| <BIT_AND: "&">
| <BIT_OR: "|">
| <XOR: "^">

But I couldn't find any issues or information about it ? Are you planning to support it ?

We would like to see bitwise operators implemented as well.

Hi guys,
Yes, the new parser already supports the syntax, but the underlying executor still lacks some components.
They will be implemented right after 2.2

It's unbelievable that it's still not supported.
I made a custom function myself like this:
var op = operator.toLowerCase();
if (op == "and" || op == "&") {
  return left & right;
} else if (op == "or" || op == "|") {
  return left | right;
} else if (op == "xor" || op == "^") {
  return left ^ right;
}
throw "Unsupported bitwise operator.";

SQL statement will be:
CREATE FUNCTION bitwise "var op = operator.toLowerCase();\nif (op == \"and\" || op == \"&\") {\n  return left & right;\n} else if (op == \"or\" || op == \"|\") {\n  return left | right;\n} else if (op == \"xor\" || op == \"^\") {\n  return left ^ right;\n}\nthrow \"Unsupported bitwise operator.\";" PARAMETERS [operator,left,right] IDEMPOTENT true LANGUAGE javascript

And usages are:
SELECT FROM Something WHERE bitwise('and', flags, 6) = 6
SELECT FROM Something WHERE bitwise('&', flags, 3) > 0
SELECT FROM Something WHERE bitwise('or', flags, 2) = 3
SELECT FROM Something WHERE bitwise('xor', flags, 1) = 2

It's inefficient obviously. Can I get another work-around maybe?

I know guys, it's in my TODO list, the parser is ready to support it, but the executor still doesn't.

@luigidellaquila
hi Luigi, any news for this functionality ? Is there some version planned in which the functionality will be present ?
thx for all the good works!

Hi @rdelangh
it is scheduled for 3.0
Thanks
Luigi

It's already implemented in v 3.0.0 M2 and will be released with the GA
Docs here http://orientdb.com/docs/3.0.x/sql/SQL-Syntax.html
Thanks
Luigi

I think on 3.0.9 bitwise AND seems to doesn't work when the value is return from a function.
select @rid, 	mode, 						/* mode = 42755 */ 	octet2dec(mode),			/* 17901 */ 	octet2dec(mode) & 0170000,  /* is 17901 but shoud be 16384 */         $a,         $b from Stat      let $a = octet2dec(mode),     $b = $a & 0170000 limit 10

Here is the body function. (x is argument)
return parseInt(x, 8);

Anyway I did my workaround and I created by custom function that calculates bitwise AND.

authors: gongdo gregaubert grzegorz-aniol luigidellaquila nethertek rdelangh


text:
Can't build master at label 2.1.11 or 2.1.12 because lucene tests are failing

On a fresh clone I can't perform a mvn clean install on the master branch (currently with label 2.1.12, but it happens also at 2.1.11):
Tests run: 30, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 22.41 sec <<< FAILURE! - in TestSuite
testInsertUpdateTransactionWithIndex(com.orientechnologies.lucene.test.LuceneInsertUpdateSingleDocumentTransactionTest)  Time elapsed: 0.231 sec  <<< FAILURE!
java.lang.AssertionError: expected [2] but found [0]
        at com.orientechnologies.lucene.test.LuceneInsertUpdateSingleDocumentTransactionTest.testInsertUpdateTransactionWithIndex(LuceneInsertUpdateSingleDocumentTransactionTest.java:97)

testInsertUpdateTransactionWithIndex(com.orientechnologies.lucene.test.LuceneInsertUpdateTransactionTest)  Time elapsed: 0.105 sec  <<< FAILURE!
java.lang.AssertionError: expected [1] but found [0]
        at com.orientechnologies.lucene.test.LuceneInsertUpdateTransactionTest.testInsertUpdateTransactionWithIndex(LuceneInsertUpdateTransactionTest.java:97)

Results :

Failed tests:
  LuceneInsertUpdateSingleDocumentTransactionTest.testInsertUpdateTransactionWithIndex:97 expected [2] but found [0]
  LuceneInsertUpdateTransactionTest.testInsertUpdateTransactionWithIndex:97 expected [1] but found [0]

Tests run: 30, Failures: 2, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] OrientDB ........................................... SUCCESS [  1.330 s]
[INFO] OrientDB Test Commons .............................. SUCCESS [  1.499 s]
[INFO] OrientDB Core ...................................... SUCCESS [01:52 min]
[INFO] OrientDB Enterprise ................................ SUCCESS [  1.133 s]
[INFO] OrientDB Client .................................... SUCCESS [  5.702 s]
[INFO] OrientDB Object .................................... SUCCESS [  6.806 s]
[INFO] OrientDB Server .................................... SUCCESS [ 49.905 s]
[INFO] OrientDB Tools ..................................... SUCCESS [  1.387 s]
[INFO] OrientDB GraphDB ................................... SUCCESS [ 38.980 s]
[INFO] OrientDB Tests ..................................... SUCCESS [04:58 min]
[INFO] OrientDB Distributed Server ........................ SUCCESS [  4.779 s]
[INFO] OrientDB Lucene full text and spatial index ........ FAILURE [ 27.249 s]
[INFO] OrientDB JDBC Driver ............................... SKIPPED
[INFO] OrientDB ETL ....................................... SKIPPED
[INFO] OrientDB Community Distribution .................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 09:10 min
[INFO] Finished at: 2016-03-02T09:19:52+01:00
[INFO] Final Memory: 160M/913M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project orientdb-lucene: There are test failures.

mvn --version prints:
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00)
Maven home: C:\Dev\apache-maven-3.3.3\bin\..
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_65\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

I've just checked out the tag 2.1.12 on master and a mvn clean install was fine:
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] OrientDB ........................................... SUCCESS [  1.035 s]
[INFO] OrientDB Test Commons .............................. SUCCESS [  1.163 s]
[INFO] OrientDB Core ...................................... SUCCESS [01:25 min]
[INFO] OrientDB Enterprise ................................ SUCCESS [  0.684 s]
[INFO] OrientDB Client .................................... SUCCESS [  3.075 s]
[INFO] OrientDB Object .................................... SUCCESS [  5.055 s]
[INFO] OrientDB Server .................................... SUCCESS [ 40.518 s]
[INFO] OrientDB Tools ..................................... SUCCESS [  0.822 s]
[INFO] OrientDB GraphDB ................................... SUCCESS [ 31.204 s]
[INFO] OrientDB Tests ..................................... SUCCESS [03:17 min]
[INFO] OrientDB Distributed Server ........................ SUCCESS [  2.377 s]
[INFO] OrientDB Lucene full text and spatial index ........ SUCCESS [ 18.294 s]
[INFO] OrientDB JDBC Driver ............................... SUCCESS [ 51.075 s]
[INFO] OrientDB ETL ....................................... SUCCESS [ 20.601 s]
[INFO] OrientDB Community Distribution .................... SUCCESS [ 13.376 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 07:52 min
[INFO] Finished at: 2016-03-02T11:10:36+01:00
[INFO] Final Memory: 186M/1597M
[INFO] ------------------------------------------------------------------------

mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.8.0_66, vendor: Azul Systems, Inc.
Java home: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.3", arch: "x86_64", family: "mac"

Our CI (jenkins) runs on Linux, and all is ok on that.

You have an OpenJDK derivate (not Oracle like me), I will try that...

I wonder if it could be the charset, but the tests doesn't use any strange char and it doesn't access to the file system to get text or resources.

Hi guys ,
I may confirm it runs OK on Linux but always have problem on windows.
ср, 2 Мар 2016, 14:05 Roberto Franchini notifications@github.com:

I wonder if it could be the charset, but the tests doesn't use any strange
char and it doesn't access to the file system to get text or resources.
—
Reply to this email directly or view it on GitHub
https://github.com/orientechnologies/orientdb/issues/5793#issuecomment-191212517
.

--
Best regards,
Andrey Lomakin, R&D lead.
OrientDB Ltd
twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin

ok, so it seems a problem with windows. I'll investigate.

@laa  can you check develop on windows?

Done, still have error
Mar 11, 2016 12:56:35 PM com.orientechnologies.common.log.OLogManager log
INFO: {db=luceneSpatial} Imported: [0] records
Tests run: 30, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 49.574 sec
<<< FAILURE! - in TestSuite
testInsertUpdateTransactionWithIndex(com.orientechnologies.lucene.test.LuceneInsertUpdateSingleDocumentTransactionTest)
Time elapsed: 0.061 sec  <<< FAILURE!
java.lang.AssertionError: expected [2] but found [0]
at
com.orientechnologies.lucene.test.LuceneInsertUpdateSingleDocumentTransactionTest.testInsertUpdateTransactionWithIndex(LuceneInsertUpdateSingleDocumentTransactionTest.java:97)
testInsertUpdateTransactionWithIndex(com.orientechnologies.lucene.test.LuceneInsertUpdateTransactionTest)
Time elapsed: 0.038 sec  <<< FAILURE!
java.lang.AssertionError: expected [1] but found [0]
at
com.orientechnologies.lucene.test.LuceneInsertUpdateTransactionTest.testInsertUpdateTransactionWithIndex(LuceneInsertUpdateTransactionTest.java:97)
On Fri, Mar 11, 2016 at 11:40 AM Roberto Franchini notifications@github.com
wrote:

@laa https://github.com/laa can you check develop on windows?
—
Reply to this email directly or view it on GitHub
https://github.com/orientechnologies/orientdb/issues/5793#issuecomment-195291752
.

--
Best regards,
Andrey Lomakin, R&D lead.
OrientDB Ltd
twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin

I need a windows box to understand the problem

I've fixed errors for Lucene on windows, they will be in upcoming 2.2.1 release

authors: Zeemee7 laa robfrank


text:
IN filter parameter binding problem

hey,
I have to queries:

SELECT EXPAND(out()[age = :value]) FROM #11:0 ORDER BY age asc
This works as expected.

SELECT EXPAND(out()[age IN :values]) FROM #11:0 ORDER BY age asc
This throws an exception.
com.orientechnologies.orient.core.exception.OQueryParsingException: Error on parsing command at position #0: Error on parsing query
Query: age IN [31, 34
------^
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.text(OSQLPredicate.java:103)
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.<init>(OSQLPredicate.java:58)
at com.orientechnologies.orient.core.record.impl.ODocumentHelper.getFieldValue(ODocumentHelper.java:470)
at com.orientechnologies.orient.core.sql.functions.coll.OSQLMethodMultiValue.execute(OSQLMethodMultiValue.java:54)
at com.orientechnologies.orient.core.sql.methods.OSQLMethodRuntime.execute(OSQLMethodRuntime.java:139)
at com.orientechnologies.orient.core.sql.filter.OSQLFilterItemAbstract.transformValue(OSQLFilterItemAbstract.java:141)
at com.orientechnologies.orient.core.sql.functions.OSQLFunctionRuntime.execute(OSQLFunctionRuntime.java:133)
at com.orientechnologies.orient.core.sql.functions.OSQLFunctionRuntime.getValue(OSQLFunctionRuntime.java:147)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.applyExpand(OCommandExecutorSQLSelect.java:2255)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.execute(OCommandExecutorSQLSelect.java:447)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLDelegate.execute(OCommandExecutorSQLDelegate.java:90)
at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.executeCommand(OAbstractPaginatedStorage.java:1433)
at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.command(OAbstractPaginatedStorage.java:1406)
at com.orientechnologies.orient.core.sql.query.OSQLQuery.run(OSQLQuery.java:72)
at com.orientechnologies.orient.core.sql.query.OSQLSynchQuery.run(OSQLSynchQuery.java:85)
at com.orientechnologies.orient.core.query.OQueryAbstract.execute(OQueryAbstract.java:33)
at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.query(ODatabaseDocumentTx.java:717)

....
Caused by: java.lang.IllegalStateException: Missing closed braket character: ']', position: 14
at com.orientechnologies.common.parser.OBaseParser.parserNextWord(OBaseParser.java:624)
at com.orientechnologies.common.parser.OBaseParser.parserNextWord(OBaseParser.java:494)
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.extractConditionItem(OSQLPredicate.java:264)
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.extractCondition(OSQLPredicate.java:195)
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.extractConditions(OSQLPredicate.java:139)
at com.orientechnologies.orient.core.sql.filter.OSQLPredicate.text(OSQLPredicate.java:93)
... 53 more
I'm using 2.1.17.
What could be the issue here?

Hi @balazsmaria
it seems to be a bug, I'll take a look at that ASAP
Thanks
Luigi

Hi @balazsmaria
I fixed it in develop and 2.1.x branches. The fix will be released with 2.1.20 and 2.2.1
Thanks
Luigi

authors: balazsmaria luigidellaquila


text:
Old Parser Deprecation for 3.0

I was was wondering if there are plans to deprecate the "non-strict" mode of Parsing some time in the future (perhaps 3.0).  As I have worked on the grammar and parsers, I have noticed that we are essentially parsing twice now.  Clearly this is inefficient, since we now parse, then generate a string, then parse again.  However, the efficiency is not the concern, it is the maintainability of the code.
The JavaCC parsing is very clean and robust.  We get nice clean objects that come out and can be used to execute commands.  I find the old style parsing to be very tricky and buggy.  There is a lot of technical debt in the old parser.
I was wondering if you have considered breaking backwards compatibility in 3.0 to the old style of parsing and migrating to only using the new parse.  This would allow us to clean up and remove a lot of code.
This could be considered a question or a feature enhancement.  So I wasn't sure where to post.
Thanks!

Hi @mmacfadden
I'll give you a precise answer: YES! 😄
The old parser is probably the oldest component in OrientDB, its first version was far smaller and less complex than current one, it evolved in an unstructured way and the result is exactly what you described.
The same is for the query executor (in fact there is no strict separation between the parser and the executor).
What we will do in v 3.0 is:

drop the old parser and leave only the JavaCC based grammar
review the whole grammar to get rid of inconsistencies and to strictly define all the behaviors, especially where we know we have some lacks (eg. usage of LET variables and aliases in WHERE condition, ORDER BY, GROUP BY, manipulation of embedded documents, review of tricky operators like expand() and distinct(), review return types for statements, especially in batch script, an many many more)
separate the parser from the executor
re-write the executor layer, logically separating the phases of

query tree optimization
execution planning
query execution

take into consideration important factors like multi-core and distributed architectures at query optimization time.

Together with this, we will also review some low level APIs to have a better management of streaming result-sets.
The goals of this challenging review are:

SQL layer consistency
stability
performance (speed, but also ability to monitor and control execution plans)
code quality

The first side-effect of all this will be for sure the deletion of a lot of old code ;-)
V 2.2 was released a couple of weeks ago, until now we concentrated on monitoring v 2.2 in the wild and fixing last-minute issues. In next few days we will officially start the development of v 3.0
Thanks
Luigi

Great.  I would love to lend a hand when the time comes.

We're getting rid of some legacy things, the SQL engine is one of the most important piece we're rewriting from scratch. I can't wait that @luigidellaquila make it.

@lvca I have been spending a lot of time with the new parser and I really like it.  I think it will allow us do more easily add new features and make the language more consistent.  And also provide better error handling.  Again, I am willing to help out!

In the v3.0 the SQL engine will be much smarter on using indexes and lighter on executing queries. This is a major version, so we're going to need much help on this ;-)

Sounds good!  It would be great if we could start a discussion thread some point in the future to work on design goals, so I can try to follow along with you guys!

Although I can't help with the programming side, I'll be supporting ODB too, as much as I can. To me, I feel 3.0 will be THE breakthrough for ODB, because the cumulation of learning over the past years will come together in 3.0. Fun times are ahead! :smile:
Scott

authors: luigidellaquila lvca mmacfadden smolinari


text:
Replace npmignore with whitelist

Fixes #32. I looked at the Makefile to make sure I wasn't missing anything—essentially this change says "include only  what is in this array when publishing to npm".
Some files are always included and don't need to be specified, and some are always ignored. See here for more info.
If I missed anything, let me know!

documentation.js also needs to be included. Could you add your name to the CONTRIBUTORS file as well? Other than that it looks good to me

Done!

Thanks :)

authors: robotlolita sotojuan

repo: origamitower/folktale


text:
Type Support: Properties with conditional types

Description
Some components work with different modelValue values based on another property.
For example, the modelValue property of the dropdown component can be a single value, or if the multiple property is true, the modelValue property will be an array of values.
These type distinctions could be solved by using conditional types for such use cases.

Help wanted:
But I don't know how to implement conditional types with the composition api. A similar question can be found here: stackoverflow.
Any suggestions for implementation are welcome.
Why Oruga need this feature
Improve component TypeScript support.

My first thought was to do something along these lines:
diff --git a/packages/oruga/src/components/dropdown/Dropdown.vue b/packages/oruga/src/components/dropdown/Dropdown.vue
index 589d4e3f..0ea6ed52 100644
--- a/packages/oruga/src/components/dropdown/Dropdown.vue
+++ b/packages/oruga/src/components/dropdown/Dropdown.vue
@@ -1,5 +1,12 @@
 <script setup lang="ts">
-import { computed, nextTick, ref, watch, type PropType } from "vue";
+import {
+    computed,
+    nextTick,
+    ref,
+    watch,
+    type PropType,
+    type ComponentObjectPropsOptions,
+} from "vue";

 import PositionWrapper from "../utils/PositionWrapper.vue";

@@ -35,11 +42,6 @@ defineOptions({
 const props = defineProps({
     /** Override existing theme classes completely */
     override: { type: Boolean, default: undefined },
-    /** @model */
-    modelValue: {
-        type: [String, Number, Boolean, Object, Array],
-        default: undefined,
-    },
     /** The active state of the dropdown, use v-model:active to make it two-way binding. */
     active: { type: Boolean, default: false },
     /** Trigger label, unnecessary when trgger slot is used */
@@ -85,8 +87,6 @@ const props = defineProps({
         type: String,
         default: () => getOption("dropdown.animation", "fade"),
     },
-    /** Allows multiple selections */
-    multiple: { type: Boolean, default: false },
     /** Trap focus inside the dropdown. */
     trapFocus: {
         type: Boolean,
@@ -237,6 +237,27 @@ const props = defineProps({
         type: [String, Array, Function] as PropType<ComponentClass>,
         default: undefined,
     },
+    ...({
+        /** @model */
+        modelValue: {
+            type: [String, Number, Boolean, Object, Array],
+            default: undefined,
+        },
+        /** Allows multiple selections */
+        multiple: { type: Boolean, default: false },
+    } satisfies ComponentObjectPropsOptions as
+        | {
+              modelValue: {
+                  type: PropType<string | number | boolean | object>;
+              };
+              multiple: { type: PropType<false> };
+          }
+        | {
+              modelValue: {
+                  type: PropType<(string | number | boolean | object)[]>;
+              };
+              multiple: { type: PropType<true> };
+          }),
 });

 const emits = defineEmits<{

I'm not sure that this will actually play nicely with the defineProps macro, though, and based on some rough testing I was doing, I don't think the type inference quite cooperates as desired.

I maybe found a solution explained in this quide: https://medium.com/@ademyalcin27/crafting-type-safe-components-in-vue-js-with-typescript-3724276c6155
I created an example PR for the input component #884.

Based on a quick glance at the PR, it seems like a pretty reasonable approach. I'd be tempted to use T as the generic argument instead of TNumber, although I don't know if that would play well with TypeScript's type inference.

Hmm, I don't like that it is not possible to define the conditional type with the runtime declaration approach and we have to use the type-based declaration approach with the withDefaults compile macro...

I have it!!

It works with the runtime declaration approach, by casting the type as unkown before declaring it properly with PropType.

My example is not working anymore :/ I think this is not the right solution...

repo: oruga-ui/oruga


text:
Set up GitLab CI

Setting up GitLab CI with just one test until new tests are added.

The gitlab CI workflow wont run before the workflow file lands in main, so we'll only see this run on a PR after it's merged.

repo: osbuild/images


text:
Use internal download mirror for Fedora images

Reduce stress on upstream mirrors and speed up builds by using an
internal mirror to download packages in CI.
Signed-off-by: Major Hayden major@redhat.com

This one is broken due to internal mirror issues for Fedora. Helpdesk ticket has been opened.

repo: osbuild/osbuild-composer


text:
Compilation breakage of 2.0.0-rc.4

To reproduce, create an empty crate, add
[dependencies]
specta = { version = "2.0.0-rc.4", features = ["typescript"] }

and run cargo check.
error[E0432]: unresolved import `crate::js_doc`
 --> .../specta-2.0.0-rc.4/src/lang/ts/comments.rs:1:5
  |
1 | use crate::js_doc;
  |     ^^^^^^^^^^^^^ no `js_doc` in the root

(Thank you for the great library, by the way! Happily use it in several pet projects.)

Thanks for reporting this should be fixed in v2.0.0-rc.5. Lemme know if it doesn't go away!

authors: Vlad-Shcherbina oscartbeaumont

repo: oscartbeaumont/specta


text:
Use SwiftUI-esque environment values and retire ProxyTextField.

This makes it easier to adopt real SwiftUI environment values when Apple realizes that making them public is the most straight forward business decision in the history of business decisions. It's the difference between an awesome 3rd party ecosystem and a barren wasteland. SwiftUI without public environment values is like UIKit without subclasses. Image how unwieldy SwiftUI would be if it used per-view modifiers such as someTextModifier(_:), someTextFieldModifier(_:), etc.
Example
keyboardType(_:) // SwiftUI
diffableTextViews_keyboardType(_:) // DiffableTextViews

Documentation
The README should contain a table of all UITextField related SwiftUI modifiers. It should show whether the modifier works, if there is a DiffableTextViews specific analogue, or if it does not work. Some things just work, like multilineTextAlignment(_:) because Apple decided to make just that one public for some reason. It should also show when the modifier is applied: on setup or on update, which should match the behavior of SwiftUI.TextField.
Edit: layoutDirection and disableAutocorrection are also public.
Considerations
It is probably a good idea to also offer analogue methods for environment values that are already exposed, because it is a lot of cognitive overhead to keep track of what works as normal and what doesn't. It's much easier to assume that everything or nothing works as normal.

Some SwiftUI.TextField environment values.

Value
Refreshes On

placeholder
update

disableAutocorrection
update

layoutDirection
update

multilineTextAlignment
update

Will add more entries when I have time to probe SwiftUI.

It's a work in progress in dev. Currently, all environment modifiers have been prefixed with diffableTextViews_, because it is too much of a headache to remember what works natively and what doesn't. Technically, multilineTextAlignment, layoutDirection and disableAutocorrection could use SwiftUI's own modifiers, because Apple was kind enough to make them public. But, I think it's better that everything or nothing is an exception to the rule, rather than mixing the two.

List of supported modifiers (dev):

environment(.locale, _:)
environment(.layoutDirection, _:)
diffableTextViews_disableAutocorrection(_:)
diffableTextViews_font(_:)
diffableTextViews_foregroundColor(_:)
diffableTextViews_multilineTextAlignment(_:)
diffableTextViews_onSubmit(_:)
diffableTextViews_submitLabel(_:)
diffableTextViews_textContentType(_:)
diffableTextViews_textFieldStyle(_:)
diffableTextViews_textInputAutocapitalization(_:)
diffableTextViews_tint(_:)

These modifiers have obvious been named to make it easy to transition to pure SwiftUI whenever Apple makes it possible.

repo: oscbyspro/DiffableTextViews


text:
Requirment for proper documentation

I want to suggest that
having a contribution.md file for providing guidance to contributors
and a readme.md file only for explaining what the project is .

Allow me to solve this issue

repo: oscfcommunity/OSWeekend-Web


text:
Create OSIAM extension programmatically

Doing it in the database migration is not a good idea. Due to the fact that each migration has a checksum, we would not be able to change what should initially be created. Example data has already been migrated to programmatic creation too.
This also contains a refactoring of the extension DAO. See the corresponding commit for details.

Updated

Thank you!

authors: dacrome tkrille

repo: osiam/osiam


text:
Seletor de restrição na base16h do OSMcode cientifico

Depois de quebrar o seletor de Level em duas linhas

Incluir um  filtro de "tipo de nível".
Tipos, faceis de definir numa planilha Excel:

all L =  Todos
L int =  Só inteiros (não entram os níveis-meio)
half L = Só meios (não entram os inteiros)
L hex = Só hexadecimas: níveis cujos geocódigos são hexadecimais puros (nada de dígitos  exóticos da base16h)
L b32 = Só base32: subconjunto da base16h que intercala inteiros e meios, pulando

Implementado em https://github.com/osm-codes/gridMap-draftPages/commit/1faf71df91364355aa10bd84f8cf0f21c882ce19 e https://github.com/osm-codes/gridMap-draftPages/commit/0282dfe4372373e78ad43c21f523e3b87f8d2b8c.

repo: osm-codes/gridMap-draftPages


text:
Timezone error on CSV export

I am trying to download task data as CSV. It gives me the following error instead of CSV data:
status | "KO"
-- | --
message | "Timezone is not a valid time zone. [null]"

Here's the timezone info MapRoulette shows me:

When I set the timezone to something sensible, the download goes through.

Unable to reproduce and couldn't locate the source challenge with @mvexel.  I will close for now and reopen if this issue pops up again.


text:
Feature request: Add support for LinkedIn

A growing number of communities have a presence on LinkedIn now. It would be good to enable communities to link to their page / group on LinkedIn.
Current "companies" on LinkedIn:

Fundación OpenStreetMap Chile
Iranian OpenStreetMap Association
OpenStreetMap Africa
OpenStreetMap Belgium
OpenStreetMap Brazil
OpenStreetMap Cote D'Ivoire ( OSMCI)
OpenStreetMap CZ
OpenStreetMap Foundation
OpenStreetMap Foundation Japan
OpenStreetMap España
OpenStreetMap France
OpenStreetMap Ghana
OpenStreetMap Ireland
OpenStreetMap Japan
OpenStreetMap Mali
OpenStreetMap Uganda
OpenStreetMap US
OpenStreetMap Taiwan
OpenStreetMap Togo

There are also a handful of groups...
Happy to do the legwork if the maintainers can provide a small amount of guidance. :)

Hi Donal,
and THANKS for your contribution! I will look into adding LinkedIn (Logo and programmatic stuff) after consulting @bhousel if he's against it.
It would be immensely helpful if you put a table in this issue listing the name, the URL and the geographical area, preferably in an ISO 639 format, which could be just a country. If it's a regional group, a county or city or something would help.
Greetings to lively Cork!
Kai

#423 shows how said list could look (ordered by region which makes adding the information easier)

and THANKS for your contribution! I will look into adding LinkedIn (Logo and programmatic stuff) after consulting @bhousel

Sure, this is ok with me.. I just added the support for linkedin type and added a logo for it in 46fd10a0 👍
I will update the contributing guide too.

Though I would limit linking to cases where some community activity happens there.

Though I would limit linking to cases where some community activity happens there.

I agree.. Anyway the support for LinkedIn resource type has been added about 6 months ago, so I'm going to close this.

authors: bhousel donalhunt kmpoppe matkoniecz

repo: osmlab/osm-community-index

license: ISC


text:
Can not open an issue in iD

cc. @ajithranka

I cannot open an issue in ID in chrome either and get the error "This page is trying to load scripts from unauthenticated sources"

Related to #209.
iD is currently served over http and gets blocked by the browser.
We don't really have a good fix for this right now.
As a workaround, try enabling loading unsafe scripts on your browser.

cc: @bhousel

Not actionable right now. Closing.

authors: Rub21 ajithranka boeleman

repo: osmlab/to-fix


text:
fatal error: concurrent map iteration and map write

System information
Osmosis version: 15.0.0
OS & Version: Ubuntu 22.04
Commit hash:
Expected behaviour
No crash.
Actual behaviour
Osmosis crashing.
Steps to reproduce the behaviour
I could not identify a way to make the system crash, but our service crashed a few times per day. The first line of the error in the logs was always fatal error: concurrent map iteration and map write.
Backtrace
The first "few" lines of our error logs:
6:31PM INF received complete proposal block hash=172527154A276A97AD36371C5C8EA881EB6F7393080AEFFAAD8DEDF926F350BD height=10264202 module=consensus
6:31PM INF finalizing commit of block hash={} height=10264202 module=consensus num_txs=3 root=1997EAF5CEF0831FC6C14E01A0A94A0A751B260CA60F17E292B7CE860F7A0A02
6:31PM INF executed block height=10264202 module=state num_invalid_txs=0 num_valid_txs=3
fatal error: concurrent map iteration and map write

goroutine 636538 [running, locked to thread]:
github.com/cosmos/iavl.NewUnsavedFastIterator({0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0x1, 0xc00103ec80, 0xc0f78e3b60, 0xc0f78e3b90)
        github.com/cosmos/iavl@v0.19.4/unsaved_fast_iterator.go:55 +0x227
github.com/cosmos/iavl.(*MutableTree).Iterator(0xc00414c0a0, {0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0xd3?)
        github.com/cosmos/iavl@v0.19.4/mutable_tree.go:216 +0x10c
github.com/cosmos/cosmos-sdk/store/iavl.(*Store).Iterator(0x45e8d6?, {0xc0efc224e0?, 0xc000076a00?, 0xc0f021ce88?}, {0xc0efc22510?, 0xc09af98ea0?, 0xc0f021cdb0?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/iavl/store.go:249 +0x31
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).iterator(0xc06bd84280, {0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0x1)
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:189 +0x126
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).Iterator(0xc0ef86c760?, {0xc0efc224e0?, 0x42f69f?, 0x425192?}, {0xc0efc22510?, 0x4314c6?, 0x24c4c20?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:174 +0x29
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).iterator(0xc0ed648c80, {0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0x1)
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:189 +0x126
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).Iterator(0xc005091b60?, {0xc0efc224e0?, 0xee0d66?, 0x203043?}, {0xc0efc22510?, 0x14?, 0x0?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:174 +0x29
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).iterator(0xc0ed666380, {0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0x1)
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:189 +0x126
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).Iterator(0x0?, {0xc0efc224e0?, 0xc02a01d0d0?, 0x7fbf3e9c80b8?}, {0xc0efc22510?, 0x7fbf8dafa688?, 0xd0?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:174 +0x29
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).iterator(0xc0ef952980, {0xc0efc224e0, 0x2e, 0x2e}, {0xc0efc22510, 0x25, 0x25}, 0x1)
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:189 +0x126
github.com/cosmos/cosmos-sdk/store/cachekv.(*Store).Iterator(0x0?, {0xc0efc224e0?, 0xc0f021d248?, 0x42f9e7?}, {0xc0efc22510?, 0x42f69f?, 0x42f69f?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/cachekv/store.go:174 +0x29
github.com/cosmos/cosmos-sdk/store/gaskv.(*Store).iterator(0xc106214c00, {0xc0efc224e0?, 0x0?, 0xc0f021d300?}, {0xc0efc22510?, 0x21?, 0x1?}, 0x10?)
        github.com/cosmos/cosmos-sdk@v0.46.10/store/gaskv/store.go:107 +0x56
github.com/cosmos/cosmos-sdk/store/gaskv.(*Store).Iterator(0x4265ff?, {0xc0efc224e0?, 0xc10d6af4c0?, 0xc0ef911440?}, {0xc0efc22510?, 0x100c0ef952980?, 0x7fbf3e2f11b0?})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/gaskv/store.go:78 +0x29
github.com/cosmos/cosmos-sdk/store/prefix.Store.Iterator({{0x2eedfb8, 0xc106214c00}, {0xc0ef911440, 0x21, 0x30}}, {0xc0a86377d0, 0xd, 0xd}, {0xc0a86377cc, 0x4, ...})
        github.com/cosmos/cosmos-sdk@v0.46.10/store/prefix/store.go:101 +0x239
github.com/CosmWasm/wasmvm/internal/api.cScan(0xc0ed7ff698, 0x140617c?, 0x7fbdc37bc298, {0x0?, 0x7fbf41f95f40?, 0x7fbf4197a770?}, {0x58?, 0x7fbf4197a890?, 0xc21881b040?}, 0x1, ...)
        github.com/CosmWasm/wasmvm@v1.1.1/internal/api/callbacks.go:280 +0x236
github.com/CosmWasm/wasmvm/internal/api._C2func_execute(0x7fbf65efa820, {0x0, 0xc0ef8c91c0, 0x20}, {0x0, 0xc04da65740, 0xbf}, {0x0, 0xc113db05a0, 0x57}, ...)
        _cgo_gotypes.go:294 +0x85
github.com/CosmWasm/wasmvm/internal/api.Execute.func1({0xc118f295d0?}, {0x28?, 0xc0ef8c91c0?, 0xc0f021db08?}, {0x8c?, 0xc04da65740?, 0x24f1bc0?}, {0x0, 0xc113db05a0, 0x57}, ...)
        github.com/CosmWasm/wasmvm@v1.1.1/internal/api/lib.go:211 +0x247
github.com/CosmWasm/wasmvm/internal/api.Execute({0x20?}, {0xc0ef8c91c0?, 0xc0?, 0x203042?}, {0xc04da65740?, 0x203042?, 0xc10829d7e0?}, {0xc113db05a0, 0x57, 0x60}, ...)
        github.com/CosmWasm/wasmvm@v1.1.1/internal/api/lib.go:211 +0x6f1
github.com/CosmWasm/wasmvm.(*VM).Execute(0xc00150e7a0, {0xc0ef8c91c0, 0x20, 0x20}, {{0x9c9e89, 0x1758f2761f7950c4, {0xc07abf2260, 0xb}}, 0x0, {{0xc00ca8d0c0, ...}}}, ...)
        github.com/CosmWasm/wasmvm@v1.1.1/lib.go:186 +0x2e5
github.com/CosmWasm/wasmd/x/wasm/keeper.Keeper.execute({{0x2ebf738, 0xc00150e350}, {0x2ef5a40, 0xc0002b0c70}, {0x2ec6b30, 0xc00026a6c0}, {0x2ebae20, 0xc00150e7c0}, {0x2eb7c00, 0xc0002e8bf8}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/keeper.go:425 +0xa3d
github.com/CosmWasm/wasmd/x/wasm/keeper.PermissionedKeeper.Execute(...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/contract_keeper.go:95
github.com/CosmWasm/wasmd/x/wasm/keeper.msgServer.ExecuteContract({{0x2ef0878?, 0xc00130b920?}}, {0x2edb398, 0xc118f294a0}, 0xc0ef8ccfa0)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/msg_server.go:139 +0x742
github.com/CosmWasm/wasmd/x/wasm/types._Msg_ExecuteContract_Handler.func1({0x2edb398, 0xc118f294a0}, {0x2768740?, 0xc0ef8ccfa0})
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/types/tx.pb.go:1005 +0x78
github.com/cosmos/cosmos-sdk/baseapp.(*MsgServiceRouter).RegisterService.func2.1({0x2edb398, 0xc118f29440}, {0x4dd986?, 0x42d0eb?}, 0x27c5e40?, 0xc0ed7ff680)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/msg_service_router.go:113 +0xd2
github.com/CosmWasm/wasmd/x/wasm/types._Msg_ExecuteContract_Handler({0x264bdc0?, 0xc00150fe20}, {0x2edb398, 0xc118f29440}, 0x2c158b0, 0xc10829d660)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/types/tx.pb.go:1007 +0x138
github.com/cosmos/cosmos-sdk/baseapp.(*MsgServiceRouter).RegisterService.func2({{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ef952ac0}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, 0x9c9e89, {0x39e016c4, ...}, ...}, ...}, ...)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/msg_service_router.go:135 +0x4ad
github.com/CosmWasm/wasmd/x/wasm/keeper.SDKMessageHandler.handleSdkMessage({{_, _}, {_, _}}, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ef952ac0}, {{0xb, 0x10}, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/handler_plugin.go:98 +0x1ac
github.com/CosmWasm/wasmd/x/wasm/keeper.SDKMessageHandler.DispatchMsg({{_, _}, {_, _}}, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ef952ac0}, {{0xb, 0x10}, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/handler_plugin.go:68 +0x29b
github.com/CosmWasm/wasmd/x/wasm/keeper.MessageHandlerChain.DispatchMsg({{_, _, _}}, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ef952ac0}, {{0xb, 0x10}, {0xc07abf2260, ...}, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/handler_plugin.go:130 +0x168
github.com/osmosis-labs/osmosis/v15/wasmbinding.(*CustomMessenger).DispatchMsg(_, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ef952ac0}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, 0x9c9e89, ...}, ...}, ...)
        github.com/osmosis-labs/osmosis/v15/wasmbinding/message_plugin.go:59 +0x19e
github.com/CosmWasm/wasmd/x/wasm/keeper.MessageDispatcher.DispatchSubmessages({{_, _}, {_, _}}, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ed666440}, {{0xb, 0x10}, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/msg_dispatcher.go:103 +0x506
github.com/CosmWasm/wasmd/x/wasm/keeper.DefaultWasmVMContractResponseHandler.Handle({{_, _}}, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ed666440}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/keeper.go:1220 +0xa2
github.com/CosmWasm/wasmd/x/wasm/keeper.(*Keeper).handleContractResponse(_, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ed666440}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, 0x9c9e89, ...}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/keeper.go:1009 +0x4b0
github.com/CosmWasm/wasmd/x/wasm/keeper.Keeper.execute({{0x2ebf738, 0xc00150e350}, {0x2ef5a40, 0xc0002b0c70}, {0x2ec6b30, 0xc00026a6c0}, {0x2ebae20, 0xc00150e7c0}, {0x2eb7c00, 0xc0002e8bf8}, ...}, ...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/keeper.go:436 +0xf5b
github.com/CosmWasm/wasmd/x/wasm/keeper.PermissionedKeeper.Execute(...)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/contract_keeper.go:95
github.com/CosmWasm/wasmd/x/wasm/keeper.msgServer.ExecuteContract({{0x2ef0878?, 0xc00130b920?}}, {0x2edb398, 0xc112c39d10}, 0xc0ea363bd0)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/keeper/msg_server.go:139 +0x742
github.com/CosmWasm/wasmd/x/wasm/types._Msg_ExecuteContract_Handler.func1({0x2edb398, 0xc112c39d10}, {0x2768740?, 0xc0ea363bd0})
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/types/tx.pb.go:1005 +0x78
github.com/cosmos/cosmos-sdk/baseapp.(*MsgServiceRouter).RegisterService.func2.1({0x2edb398, 0xc112c39cb0}, {0x4dd986?, 0x42d0eb?}, 0x27c5e40?, 0xc0ea371b60)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/msg_service_router.go:113 +0xd2
github.com/CosmWasm/wasmd/x/wasm/types._Msg_ExecuteContract_Handler({0x264bdc0?, 0xc00150fe20}, {0x2edb398, 0xc112c39cb0}, 0x2c158b0, 0xc10a21c380)
        github.com/CosmWasm/wasmd@v0.30.0/x/wasm/types/tx.pb.go:1007 +0x138
github.com/cosmos/cosmos-sdk/baseapp.(*MsgServiceRouter).RegisterService.func2({{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ed666440}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, 0x9c9e89, {0x39e016c4, ...}, ...}, ...}, ...)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/msg_service_router.go:135 +0x4ad
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runMsgs(_, {{0x2edb328, 0xc000056050}, {0x2ef1e80, 0xc0ed666440}, {{0xb, 0x10}, {0xc07abf2260, 0xb}, 0x9c9e89, ...}, ...}, ...)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/baseapp.go:801 +0x5a5
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runTx(0xc0002a96c0, 0x2, {0xc1090558c0, 0x231, 0x240})
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/baseapp.go:743 +0xc05
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).Simulate(0x42f9e7?, {0xc1090558c0?, 0x2602160?, 0xc0ed648701?})
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/test_helpers.go:23 +0x2c
github.com/cosmos/cosmos-sdk/x/auth/tx.txServer.Simulate({{{0x0, 0x0, 0x0}, {0x2efffd0, 0xc00ac7d1a0}, {0x0, 0x0}, {0x2ee4070, 0xc0014a8dc0}, 0x0, ...}, ...}, ...)
        github.com/cosmos/cosmos-sdk@v0.46.10/x/auth/tx/service.go:117 +0x129
github.com/cosmos/cosmos-sdk/types/tx._Service_Simulate_Handler.func1({0x2edb398, 0xc112c30060}, {0x270dd40?, 0xc2125451a0})
        github.com/cosmos/cosmos-sdk@v0.46.10/types/tx/service.pb.go:752 +0x78
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).RegisterGRPCServer.func1({0x2edb398, 0xc11818ba70}, {0x270dd40, 0xc2125451a0}, 0xc2125451c0?, 0xc0ea370708)
        github.com/cosmos/cosmos-sdk@v0.46.10/baseapp/grpcserver.go:66 +0x3d5
github.com/grpc-ecosystem/go-grpc-middleware.ChainUnaryServer.func1.1.1({0x2edb398?, 0xc11818ba70?}, {0x270dd40?, 0xc2125451a0?})

...

This is the longest stack trace I've ever seen (~50k lines). I can send you the full logs if you want.

Hey @heitorPB . Thanks for the issue. Do you have  concurrency = false in app.toml?

Yes, we have concurrency = false in there.

Have you tried upgrading to v15.1.0?
https://github.com/osmosis-labs/osmosis/releases/tag/v15.1.0
There was a security advisory and a wasmvm upgrade. I'm seeing wasmvm in the call stack so might be related

Oh, nice. It's on my TODO list but I haven't had time to update it yet. Will update today.
Do you want more lines of the errors? It is quite long, but I can find a way to send you.

This should now be fixed

authors: ValarDragon heitorPB p0mvn

repo: osmosis-labs/osmosis


text:
Bech32 Forwarding

[X] Setup relayer (osmosis-testnet-0 to vega-testnet)
[X] Create gov prop to match cosmos prefix (cosmos) to channel id (channel-42)
[ ] Send to non osmo1 prefix (in this case cosmo1 to vega testnet)
[ ] #589

Currently creation of ibc prop via osmosisd tx bech32ibc update-hrp-ibc-record is impossible due to bug (cannot add address as --from flag https://github.com/osmosis-labs/bech32-ibc/blob/master/x/bech32ibc/client/cli/tx.go#L100-L106)

Bug fix added to main. Implemented https://github.com/osmosis-labs/cosmos-sdk/commit/7b70f266a5a03447049c0ca98c4e36104a07dd93 locally to post tx (wont take anything other than osmo1 prefix otherwise). Currently blocked on tx giving success with hash but I don't believe it's making it through the relayer.

Got successful tx by updating testnet to v6.2.0
code: 0
codespace: ""
data: 0A1E0A1C2F636F736D6F732E62616E6B2E763162657461312E4D736753656E64
gas_used: "87481"
gas_wanted: "350000"
height: "3060753"
info: ""
logs:
- events:
 - attributes:
  - key: receiver
   value: osmo1uf085y7mpup6hl5cactwgnt5dfuysh5z63h42g
  - key: amount
   value: 5000000uosmo
  type: coin_received
 - attributes:
  - key: spender
   value: osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l
  - key: amount
   value: 5000000uosmo
  type: coin_spent
 - attributes:
  - key: sender
   value: osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l
  - key: receiver
   value: cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v
  type: ibc_transfer
 - attributes:
  - key: action
   value: /cosmos.bank.v1beta1.MsgSend
  - key: sender
   value: osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l
  - key: module
   value: ibc_channel
  - key: module
   value: transfer
  type: message
 - attributes:
  - key: packet_data
   value: '{"amount":"5000000","denom":"uosmo","receiver":"cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v","sender":"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l"}'
  - key: packet_data_hex
   value: 7b22616d6f756e74223a2235303030303030222c2264656e6f6d223a22756f736d6f222c227265636569766572223a22636f736d6f73317773676a776b75356339347372323937356c6577707234326c3076336638366d396d61783376222c2273656e646572223a226f736d6f31717965373732716a65383870376767747a72766c396e7876747936646b7575736b6b6735326c227d
  - key: packet_timeout_height
   value: 0-8252515
  - key: packet_timeout_timestamp
   value: "0"
  - key: packet_sequence
   value: "1"
  - key: packet_src_port
   value: transfer
  - key: packet_src_channel
   value: channel-42
  - key: packet_dst_port
   value: transfer
  - key: packet_dst_channel
   value: channel-209
  - key: packet_channel_ordering
   value: ORDER_UNORDERED
  - key: packet_connection
   value: connection-1138
  type: send_packet
 - attributes:
  - key: recipient
   value: osmo1uf085y7mpup6hl5cactwgnt5dfuysh5z63h42g
  - key: sender
   value: osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l
  - key: amount
   value: 5000000uosmo
  type: transfer
 log: ""
 msg_index: 0
raw_log: '[{"events":[{"type":"coin_received","attributes":[{"key":"receiver","value":"osmo1uf085y7mpup6hl5cactwgnt5dfuysh5z63h42g"},{"key":"amount","value":"5000000uosmo"}]},{"type":"coin_spent","attributes":[{"key":"spender","value":"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l"},{"key":"amount","value":"5000000uosmo"}]},{"type":"ibc_transfer","attributes":[{"key":"sender","value":"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l"},{"key":"receiver","value":"cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v"}]},{"type":"message","attributes":[{"key":"action","value":"/cosmos.bank.v1beta1.MsgSend"},{"key":"sender","value":"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l"},{"key":"module","value":"ibc_channel"},{"key":"module","value":"transfer"}]},{"type":"send_packet","attributes":[{"key":"packet_data","value":"{\"amount\":\"5000000\",\"denom\":\"uosmo\",\"receiver\":\"cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v\",\"sender\":\"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l\"}"},{"key":"packet_data_hex","value":"7b22616d6f756e74223a2235303030303030222c2264656e6f6d223a22756f736d6f222c227265636569766572223a22636f736d6f73317773676a776b75356339347372323937356c6577707234326c3076336638366d396d61783376222c2273656e646572223a226f736d6f31717965373732716a65383870376767747a72766c396e7876747936646b7575736b6b6735326c227d"},{"key":"packet_timeout_height","value":"0-8252515"},{"key":"packet_timeout_timestamp","value":"0"},{"key":"packet_sequence","value":"1"},{"key":"packet_src_port","value":"transfer"},{"key":"packet_src_channel","value":"channel-42"},{"key":"packet_dst_port","value":"transfer"},{"key":"packet_dst_channel","value":"channel-209"},{"key":"packet_channel_ordering","value":"ORDER_UNORDERED"},{"key":"packet_connection","value":"connection-1138"}]},{"type":"transfer","attributes":[{"key":"recipient","value":"osmo1uf085y7mpup6hl5cactwgnt5dfuysh5z63h42g"},{"key":"sender","value":"osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l"},{"key":"amount","value":"5000000uosmo"}]}]}]'
timestamp: "2022-01-27T21:04:05Z"
tx:
 '@type': /cosmos.tx.v1beta1.Tx
 auth_info:
  fee:
   amount: []
   gas_limit: "350000"
   granter: ""
   payer: ""
  signer_infos:
  - mode_info:
    single:
     mode: SIGN_MODE_DIRECT
   public_key:
    '@type': /cosmos.crypto.secp256k1.PubKey
    key: A9zC0Sa0VCK/lVLi1Kv0C1c0MQp47d+yjFqb6dAUza0a
   sequence: "187"
 body:
  extension_options: []
  memo: ""
  messages:
  - '@type': /cosmos.bank.v1beta1.MsgSend
   amount:
   - amount: "5000000"
    denom: uosmo
   from_address: osmo1qye772qje88p7ggtzrvl9nxvty6dkuuskkg52l
   to_address: cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v
  non_critical_extension_options: []
  timeout_height: "0"
 signatures:
 - PG4+OvNTqU+NFivEKadCoXvUU+ntRSHJc+G1Z3t5dfAtUXFcvwvtd28aEK01Pyx3kc4bUS0LA878Flh+BFAsKA==
txhash: 21538C7697AD12CA71F3B700C438B5910DB88F3C75BB9C5642276761759BA287

Successful bech32ibc forward complete!
relay@HETZNER-RELAYER-2:~/hermes$ hermes tx raw packet-recv vega-testnet osmosis-testnet-0 transfer channel-47 && \
> hermes tx raw packet-ack vega-testnet osmosis-testnet-0 transfer channel-47 && \
> hermes tx raw packet-recv osmosis-testnet-0 vega-testnet transfer channel-219 && \
> hermes tx raw packet-ack osmosis-testnet-0 vega-testnet transfer channel-219
2022-01-28T23:40:17.259182Z  INFO ThreadId(01) using default configuration from '/home/relay/.hermes/config.toml'
Success: []
2022-01-28T23:40:17.658394Z  INFO ThreadId(01) using default configuration from '/home/relay/.hermes/config.toml'
Success: []
2022-01-28T23:40:18.120992Z  INFO ThreadId(01) using default configuration from '/home/relay/.hermes/config.toml'
Success: []
2022-01-28T23:40:18.474593Z  INFO ThreadId(01) using default configuration from '/home/relay/.hermes/config.toml'
2022-01-28T23:40:18.877101Z DEBUG ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] packets that have acknowledgments on vega-testnet: [Some(1)..Some(1)] (total=1)
2022-01-28T23:40:18.877203Z DEBUG ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] ack packets to send out to osmosis-testnet-0 of the ones with acknowledgments on vega-testnet: 1 (first 10 shown here; total=1)
2022-01-28T23:40:18.937085Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] found unprocessed WriteAcknowledgement events for [Sequence(1)] (first 10 shown here; total=1)
2022-01-28T23:40:18.937203Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] generate messages from batch with 1 events
2022-01-28T23:40:18.965909Z DEBUG ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] vega-testnet => WriteAcknowledgementEv(WriteAcknowledgement - h:0-8417776, seq:1, path:channel-47/transfer->channel-219/transfer, toh:0-8418604, tos:Timestamp(NoTimestamp)))
2022-01-28T23:40:19.070939Z TRACE ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] built acknowledgment msg seq:1, path:channel-47/transfer->channel-219/transfer, toh:0-8418604, tos:Timestamp(NoTimestamp)), proofs at height 0-8417777
2022-01-28T23:40:19.071211Z DEBUG ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] osmosis-testnet-0 <= /ibc.core.channel.v1.MsgAcknowledgement from WriteAcknowledgementEv(WriteAcknowledgement - h:0-8417776, seq:1, path:channel-47/transfer->channel-219/transfer, toh:0-8418604, tos:Timestamp(NoTimestamp)))
2022-01-28T23:40:19.071344Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] scheduling op. data with 1 msg(s) for Destination (height 0-8417777)
2022-01-28T23:40:19.071413Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] ready to fetch a scheduled op. data with batch of size 1 targeting Destination
2022-01-28T23:40:19.071465Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] relay op. data of 1 msgs(s) to Destination (height 0-8417777), delayed by: 75.924µs [try 1/5]
2022-01-28T23:40:19.071555Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] prepending Destination client update @ height 0-8417777
2022-01-28T23:40:22.209826Z TRACE ThreadId(42) light client verification trusted=0-8417604 target=0-8417777
2022-01-28T23:40:22.576133Z TRACE ThreadId(42) adjusting headers with 0 supporting headers trusted=0-8417604 target=8417777
2022-01-28T23:40:22.576206Z TRACE ThreadId(42) fetching header height=0-8417605
2022-01-28T23:40:22.780765Z DEBUG ThreadId(01) [vega-testnet -> osmosis-testnet-0:07-tendermint-1477] MsgUpdateAnyClient from trusted height 0-8417604 to target height 0-8417777
2022-01-28T23:40:22.782819Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] assembled batch of 2 message(s)
2022-01-28T23:40:22.783182Z DEBUG ThreadId(83) send_messages_and_wait_commit with 2 messages
2022-01-28T23:40:22.837260Z DEBUG ThreadId(83) [osmosis-testnet-0] send_tx: retrieved account sequence=52 number=101355
2022-01-28T23:40:22.837446Z DEBUG ThreadId(83) [osmosis-testnet-0] send_tx: sending 2 messages using account sequence 52
2022-01-28T23:40:22.840706Z DEBUG ThreadId(83) [osmosis-testnet-0] send_tx: max fee, for use in tx simulation: Fee { amount: "240001uosmo", gas_limit: 24000000 }
2022-01-28T23:40:22.945930Z DEBUG ThreadId(83) [osmosis-testnet-0] estimate_gas: tx simulation successful, gas amount used: 158518
2022-01-28T23:40:22.946995Z DEBUG ThreadId(83) [osmosis-testnet-0] send_tx: using 158518 gas, fee Fee { amount: "1744uosmo", gas_limit: 174370 }
2022-01-28T23:40:22.985976Z DEBUG ThreadId(83) [osmosis-testnet-0] send_tx: broadcast_tx_sync: Response { code: Ok, data: Data([]), log: Log("[]"), hash: transaction::Hash(7237692A240B97A8570C52ACEC7F968CBB971EA09A971F8D0B2C5A5986026C81) }
2022-01-28T23:40:22.986240Z  INFO ThreadId(83) [osmosis-testnet-0] waiting for commit of tx hashes(s) 7237692A240B97A8570C52ACEC7F968CBB971EA09A971F8D0B2C5A5986026C81
2022-01-28T23:40:28.103998Z TRACE ThreadId(83) [osmosis-testnet-0] wait_for_block_commits: retrieved 1 tx results after 16 tries (4917ms)
2022-01-28T23:40:28.104314Z  INFO ThreadId(01) [Sync->osmosis-testnet-0] result events:
        UpdateClientEv(h: 0-3079822, cs_h: 07-tendermint-1477(0-8417777))
        AcknowledgePacketEv(h:0-3079822, seq:1, path:channel-47/transfer->channel-219/transfer, toh:0-8418604, tos:Timestamp(NoTimestamp)))

2022-01-28T23:40:28.104653Z  INFO ThreadId(01) [vega-testnet:transfer/channel-219 -> osmosis-testnet-0] success
Success: [
    UpdateClient(
        UpdateClient {
            common: Attributes {
                height: Height {
                    revision: 0,
                    height: 3079822,
                },
                client_id: ClientId(
                    "07-tendermint-1477",
                ),
                client_type: Tendermint,
                consensus_height: Height {
                    revision: 0,
                    height: 8417777,
                },
            },
            header: Some(
                Tendermint(
                     Header {...},
                ),
            ),
        },
    ),
    AcknowledgePacket(
        AcknowledgePacket {
            height: Height {
                revision: 0,
                height: 3079822,
            },
            packet: Packet {
                sequence: Sequence(
                    1,
                ),
                source_port: PortId(
                    "transfer",
                ),
                source_channel: ChannelId(
                    "channel-47",
                ),
                destination_port: PortId(
                    "transfer",
                ),
                destination_channel: ChannelId(
                    "channel-219",
                ),
                data: [],
                timeout_height: Height {
                    revision: 0,
                    height: 8418604,
                },
                timeout_timestamp: Timestamp {
                    time: None,
                },
            },
        },
    ),
]
relay@HETZNER-RELAYER-2:~/hermes$ gaiad q bank balances cosmos1wsgjwku5c94sr2975lewpr42l0v3f86m9max3v --node http://localhost:7011                                                           balances:
- amount: "5000000"
  denom: ibc/2B416C8E2EBA12591CA2EC96D9E4E3E7968AFEE7B5CF95AE6C4A6E3F2E9F1099
- amount: "99998999637"
  denom: uatom
pagination:
  next_key: null
  total: "0"


text:
feat/fix(fees): fix fee claiming by updating position accumulator value to fee growth outside

Closes: #XXX
What is the purpose of the change
Discovered by @czarcas7ic
Previously, when we claimed the fees, we used the default claim logic that does not account for custom range positions.
With concentrated liquidity, accumulator positions track fee growth outside. As a result, a new method ClaimRewardsCustomAcc is introduced in the accum package in this PR.
Additionally, tests added for CollectFees to ensure that the position fee accumulator is not updated to the global fee growth value.
To implement this test, a new method GetPositionValue was introduced in the accum package.
Brief Changelog

implement and test ClaimRewardsCustomAcc
fix the bug in CollectFees by calling the new claim function
implement and test GetPositionValue
use GetPositionValue to test that the position accumulator in CollectFees is not equal to the global fee growth accumulator.

Testing and Verifying
This change added tests
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? no
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? no
How is the feature or change documented? not applicable

Will describe in today's call why this needs further changes to completely work. Deleted my previous in line comments since the problem was involving more than what I just pointed out.

Here is the commit I made on my branch with all the fixes https://github.com/osmosis-labs/osmosis/commit/b45eb46a5477dc55136868a12e4a1de404dd6748

synched offline - pursuing another direction for fixes


text:
Remove wasm times from our antehandler checkTx + recheckTx stack

These codepaths get called in checktx and rechecktx, causing notable overhead. This PR removes these.
We should get this into a patch release to significantly improve our spam resistance

spellcheck failure is unrelated to this PR

but that was never the job of CheckTx to do, e.g. thats not done for swaps!


text:
Allow filtering of dependency graph view

As an architect, I want to filter the services that are shown in the dependency graph view in order to view a subset of the application that is currently relevant to me.

@MBuchalik any ideas to reuse the existing components in that regard?

My idea is to integrate as many features as possible into the page. For instance, in #107 we said that we want to have a page for Responsibles. But instead of adding a separate page, we could simply add a button in the grey left side bar that lets the user configure what is shown. By default, we show the Group tree. But if the user wants to, he/she can make the side bar show the services grouped by Responsible, or by Tag, or by whatever.

The reason why I am mentioning it here is because this shows that we could reduce the number of separate pages without losing any funcitonality. And we gain a few nice features like the ability to remember the filter the user has set.

Will be solved by #128.
Closing since duplicate.

authors: MBuchalik georg-schwarz

repo: osrgroup/msadoc


text:
Improve license selection for AOSD

Please have a look at the individual commit messages for the details.

Merging despite the unrelated Gradle test failures.

repo: oss-review-toolkit/ort


text:
Detect use of unsafe language features

Via static analysis where possible.
e.g.

JNDI
Unsafe code in memory safe languages

Depends on #519

authors: maxfisher-g oliverchang

repo: ossf/package-analysis


text:
:seedling: Parallelize builds

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] PR title follows the guidelines defined in  https://github.com/ossf/scorecard/blob/main/CONTRIBUTING.md#pr-process

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)
The builds were sequential.

What is the new behavior (if this is a feature change)?

parallelize builds
uses the GitHub CI as separate jobs to parallelize builds.
GitHub CI Jobs still refer to the makefile targets

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Codecov Report

Merging #1653 (681d442) into main (1aff6db) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 681d442 differs from pull request most recent head b8ca003. Consider uploading reports for the commit b8ca003 to get more accurate results

@@           Coverage Diff           @@
##             main    #1653   +/-   ##
=======================================
  Coverage   56.10%   56.10%
=======================================
  Files          72       72
  Lines        6495     6495
=======================================
  Hits         3644     3644
  Misses       2606     2606
  Partials      245      245

authors: codecov-commenter naveensrinivasan

repo: ossf/scorecard


text:
H265: srs接收 h265 flv rtmp流,报错3001

描述(Description)

描述你遇到了什么问题(Please description your issue here)

SRS版本(Version): feature/h2165

SRS的日志如下(Log):
[2021-01-21 12:05:17.320][Trace][234021][057468g9] connect app, tcUrl=rtmp://127.0.0.1:1935/live, pageUrl=, swfUrl=, schema=rtmp, vhost=127.0.0.1, port=1935, app=live, args=null
[2021-01-21 12:05:17.320][Trace][234021][057468g9] protocol in.buffer=0, in.ack=0, out.ack=0, in.chunk=128, out.chunk=128
[2021-01-21 12:05:17.400][Trace][234021][057468g9] client identified, type=fmle-publish, vhost=127.0.0.1, app=live, stream=livestream, param=, duration=0ms
[2021-01-21 12:05:17.400][Trace][234021][057468g9] connected stream, tcUrl=rtmp://127.0.0.1:1935/live, pageUrl=, swfUrl=, schema=rtmp, vhost=defaultVhost, port=1935, app=live, stream=livestream, param=, args=null
[2021-01-21 12:05:17.400][Trace][234021][057468g9] source url=/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, source_id=/
[2021-01-21 12:05:17.480][Trace][234021][057468g9] ignore disabled exec for vhost=defaultVhost
[2021-01-21 12:05:17.480][Trace][234021][057468g9] start publish mr=0/350, p1stpt=20000, pnt=5000, tcp_nodelay=0
[2021-01-21 12:05:17.522][Trace][234021][057468g9] got metadata, width=7680, height=3840, vcodec=12, acodec=10
[2021-01-21 12:05:17.522][Trace][234021][057468g9] 117B video sh,  codec(12, profile=Other, level=Other, 0x0, 0kbps, 0.0fps, 0.0s)
[2021-01-21 12:05:17.522][Trace][234021][057468g9] 7B audio sh, codec(10, profile=LC, 2channels, 0kbps, 48000HZ), flv(16bits, 2channels, 44100HZ)
[2021-01-21 12:05:17.522][Trace][234021][057468g9] 117B video sh,  codec(12, profile=Other, level=Other, 0x0, 0kbps, 0.0fps, 0.0s)
[2021-01-21 12:05:17.523][Error][234021][057468g9][11] nal_len_size:3, PictureLength:1280689, i:1280683, 0x1373368.(Resource temporarily unavailable)
[2021-01-21 12:05:17.524][Trace][234021][057468g9] cleanup when unpublish
[2021-01-21 12:05:17.524][Trace][234021][057468g9] TCP: before dispose resource(RtmpConn)(0x13898b0), conns=2, zombies=0, ign=0, inz=0, ind=0
[2021-01-21 12:05:17.524][Error][234021][057468g9][4] serve error code=3001 : service cycle : rtmp: stream service : rtmp: receive thread : handle publish message : rtmp: consume message : rtmp: consume video : hub consume video : format consume video : demux hevc NALU : avc demux ibmf : avc decode NALU size

SRS的配置如下(Config):

listen              1935;
max_connections     1000;
srs_log_tank        file;
srs_log_file        ./objs/srs.log;
http_api {
enabled         on;
listen          1985;
}
http_server {
enabled         on;
listen          8080;
dir             ./objs/nginx/html;
}
stats {
network         0;
disk            sda sdb xvda xvdb;
}
vhost defaultVhost {
}
重现(Replay)
使用下面的步骤修改ffmpeg代码，使用ffmpeg推流 h265 flv rtmp流到srs
https://blog.csdn.net/smallhujiu/article/details/81703434
期望行为(Expect)
feature/h265 srs能支持收流并转出。

Fixed in SRS 6

authors: liujinpengtommy winlinvip

repo: ossrs/srs