text:
Transient issues in backend tests

As of today, September 2023, we experience frequent Engine and Stdlib transient job failures. This issue serves as a list of all these issues so that we can keep track of them.

[x] RefactoringTests - rename project

https://github.com/enso-org/enso/actions/runs/6098519307/job/16548518988?pr=7751#step:10:7210
https://github.com/enso-org/enso/actions/runs/6081506750/job/16542318567?pr=7599#step:10:7207

[ ] InliningBuiltinsTest (NoSuchMethodError)

https://github.com/enso-org/enso/actions/runs/6147863209/job/16680272086?pr=7794#step:10:4583
https://github.com/enso-org/enso/actions/runs/6148637750/job/16682766510?pr=7756#step:10:4678

[ ] sbt: ServerAlreadyBootingException (java.io.IOException: Could not create lock for \\.\pipe\sbt-load-802998070017202719_lock, error 1336)

https://github.com/enso-org/enso/actions/runs/6098519307/job/16548520260?pr=7751#step:10:707
https://github.com/enso-org/enso/actions/runs/6238498583/job/16934446773?pr=7847#step:10:676

[x] Enso tests failures in Excel

https://github.com/enso-org/enso/actions/runs/6107071447/job/16573353177?pr=7718#step:10:10340
https://github.com/enso-org/enso/actions/runs/6149491753/job/16685489613?pr=7793#step:10:9902 (File not found exception)

[x] Native Image build failed with "Image generator watchdog detected no activity"

Reported as #7850

[ ] Error in Rust build script "HTTP status server error (503 Service Unavailable)"

https://github.com/enso-org/enso/actions/runs/6082740008/job/16501130768?pr=7726#step:10:560
LoggerInitializationException
https://github.com/enso-org/enso/actions/runs/6111204906/job/16585910923?pr=7751#step:10:7553

[ ] org.enso.interpreter.test.instrument.RuntimeErrorsTest: lllegalStateException: "The language did not complete all polyglot threads but should have"

https://github.com/enso-org/enso/actions/runs/6149491753/job/16720398230?pr=7793#step:10:6666

[x] org.enso.interpreter.test.instrument.RuntimeServerTest: should recompute expressions changing an execution environment

https://github.com/enso-org/enso/actions/runs/6380739479/job/17315711946?pr=7840#step:10:3778

[ ] Failed to upload file project-manager-windows.tar.gz

https://github.com/enso-org/enso/actions/runs/6186164135/job/16793186901?pr=7807

[ ] [org.apache.commons.io.IOIndexedException: IOException #0: Cannot delete file: C:\Users\ContainerAdministrator\AppData\Local\Temp\enso-test9984012585562224382\installed\log\enso-launcher-2023-09-19.log]

https://github.com/enso-org/enso/actions/runs/6237105771/job/16929910573?pr=7825#step:10:6222

[ ] [collect2: error: ld returned 1 exit status]

https://github.com/enso-org/enso/actions/runs/6340868084/job/17223234362?pr=7918

[ ] language server test "ReceivesTreeUpdateHandler" timeout:

https://github.com/enso-org/enso/actions/runs/6351538769/job/17252919996?pr=7883#step:10:4126
https://github.com/enso-org/enso/actions/runs/6380394667/job/17314693145#step:10:4479
https://github.com/enso-org/enso/actions/runs/6382365087/job/17320800859?pr=7929#step:10:4190

[x] "[live]" did not equal "[design]" (RuntimeServerTest.scala:4359)

https://github.com/enso-org/enso/actions/runs/6410804439/job/17420283503?pr=7953

[ ] Error: listen EADDRINUSE: address already in use :::47308

https://github.com/enso-org/enso/actions/runs/6547498818/job/17780102906?pr=8080

[x] java.util.ServiceConfigurationError: org.enso.base.file_format.FileFormatSPI: Provider org.enso.database.EnsoConnectionSPI not found (mixing artifacts from different builds https://github.com/enso-org/enso/pull/8006) #8129
~~https://github.com/enso-org/enso/actions/runs/6549252500/job/17785756996?pr=8093~~
[ ] assertion failed: timeout (5 seconds) during expectMsgClass waiting for class java.lang.String in ReceivesTreeUpdatesHandlerTest

https://github.com/enso-org/enso/actions/runs/6642894609/job/18048711561?pr=8145

[ ] /Standard/Base/0.0.0-dev/src/Data.enso: error: The module Standard.Base.Data.Enso_Cloud does not exist.

https://github.com/enso-org/enso/actions/runs/6655553215/job/18086068902?pr=8146#step:10:3448

Issues with the project rename tests should be fixed by #7794

Added to the list: InliningBuiltinsTest (NoSuchMethodError on Windows) - https://github.com/enso-org/enso/actions/runs/6147863209/job/16680272086?pr=7794#step:10:4583

"Enso test failures in Excel" transient failures - After discussion with @JaroslavTulach, we think that the issue might be cause by enso_project.data returning a different directory than expected. Probably caused by a GC issue in https://github.com/enso-org/enso/blob/develop/engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/EnsoProjectNode.java#L96C12-L96C12. Diagnostics added in https://github.com/enso-org/enso/pull/7793/commits/7f9c05d4d64575919cc3054447c5c77a7c798579

Added to the list: java.io.IOException: Could not create lock for \\.\pipe\sbt-load-802998070017202719_lock, error 1336

https://github.com/enso-org/enso/actions/runs/6238498583/job/16934446773?pr=7847

Added to the list: java.io.IOException: Could not create lock for \\.\pipe\sbt-load-802998070017202719_lock, error 1336
* https://github.com/enso-org/enso/actions/runs/6238498583/job/16934446773?pr=7847

 GitHub**Improve HTTP tests · enso-org/enso@fc8ad0e**Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

This is actually the same error as under sbt: ServerAlreadyBootingException category - https://github.com/enso-org/enso/actions/runs/6238498583/job/16934446773?pr=7847#step:10:676. Moving it up in the list.

I added to the list an error I saw on my CI build:
 INFO ide_ci::program::command: sbtℹ /runner/_work/enso/enso/distribution/lib/Standard/Base/0.0.0-dev/src/Data.enso: error: The module Standard.Base.Data.Enso_Cloud does not exist.
 INFO ide_ci::program::command: sbtℹ [error] Test org.enso.interpreter.test.MetaIsATest.checkNumberIsNotInstanceOfNumber failed: org.graalvm.polyglot.PolyglotException: Compilation aborted due to errors., took 0.066 sec
 INFO ide_ci::program::command: sbtℹ [error]     at org.graalvm.polyglot.Value.invokeMember(Value.java:974)
 INFO ide_ci::program::command: sbtℹ [error]     at org.enso.interpreter.test.ValuesGenerator.v(ValuesGenerator.java:71)
 INFO ide_ci::program::command: sbtℹ [error]     at org.enso.interpreter.test.ValuesGenerator.v(ValuesGenerator.java:60)
 INFO ide_ci::program::command: sbtℹ [error]     at org.enso.interpreter.test.ValuesGenerator.typeNumber(ValuesGenerator.java:157)
 INFO ide_ci::program::command: sbtℹ [error]     at org.enso.interpreter.test.MetaIsATest.checkNumberIsNotInstanceOfNumber(MetaIsATest.java:150)
 INFO ide_ci::program::command: sbtℹ [error]     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 INFO ide_ci::program::command: sbtℹ [error]     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 INFO ide_ci::program::command: sbtℹ [error]     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 INFO ide_ci::program::command: sbtℹ [error]     at java.lang.reflect.Method.invoke(Method.java:568)
 INFO ide_ci::program::command: sbtℹ [error]     ...

So apparently it looks like an import Standard.Base.Data.Enso_Cloud that comes from a different PR must have somehow leaked to my branch.

I added one more to the list - the startup time benchmark seems to be failing from time to time with
 INFO ide_ci::program::command: cmdℹ Found 2 cases to execute (ETA 50s)
 INFO ide_ci::program::command: cmdℹ Benchmarking 'Startup.empty_startup' with configuration: [warmup={2 iterations, 5 seconds each}, measurement={3 iterations, 5 seconds each}]
 INFO ide_ci::program::command: cmdℹ Execution finished with an error: Cannot find enso-engine-* in C:\runner\_work\enso\enso\built-distribution
ERROR ide_ci::program::command: cmdℹ Failed to decode a line from output: invalid utf-8 sequence of 1 bytes from index 5
 WARN ide_ci::program::command: cmdℹ Raw buffer: [67, 58, 92, 114, 32, 133, 13]. Decoded with placeholders: C:\r �
 INFO ide_ci::program::command: cmdℹ         at <enso> Panic.throw(Internal)
 INFO ide_ci::program::command: cmdℹ         at <enso> find_prefix<arg-2>(src\Startup\Startup.enso:55:13-27)
 INFO ide_ci::program::command: cmdℹ         at <enso> find_prefix(src\Startup\Startup.enso:51-55)
 INFO ide_ci::program::command: cmdℹ         at <enso> Startup.enso_bin(src\Startup\Startup.enso:60:19-63)
 INFO ide_ci::program::command: cmdℹ         at <enso> suspended-block<arg-1>(src\Startup\Startup.enso:37:20-27)
 INFO ide_ci::program::command: cmdℹ         at <enso> null(Internal)
 INFO ide_ci::program::command: cmdℹ         at <enso> Data.enso_bin(Internal)
 INFO ide_ci::program::command: cmdℹ         at <enso> Data.startup(src\Startup\Startup.enso:18:15-27)
 INFO ide_ci::program::command: cmdℹ         at <enso> Data.bench_empty(src\Startup\Startup.enso:12:9-58)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous><arg-2>(src\Startup\Startup.enso:40:47-62)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:74:54-62)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous><arg-4>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:172:58-65)
 INFO ide_ci::program::command: cmdℹ         at <enso> Runtime.no_inline(Internal)
 INFO ide_ci::program::command: cmdℹ         at <enso> Bench.type.single_call(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:214:13-33)
 INFO ide_ci::program::command: cmdℹ         at <enso> case_branch(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:196:31-51)
 INFO ide_ci::program::command: cmdℹ         at <enso> Bench.type.measure(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:194-207)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:172:13-66)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:135:60-70)
 INFO ide_ci::program::command: cmdℹ         at <enso> f(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Vector.enso:258:26-50)
 INFO ide_ci::program::command: cmdℹ         at <enso> go<arg-2>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:312:31-50)
 INFO ide_ci::program::command: cmdℹ         at <enso> go(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:311-313)
 INFO ide_ci::program::command: cmdℹ         at <enso> Range.fold<arg-2>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:314:13-30)
 INFO ide_ci::program::command: cmdℹ         at <enso> Range.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:308-314)
 INFO ide_ci::program::command: cmdℹ         at <enso> Vector.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Vector.enso:259:9-41)
 INFO ide_ci::program::command: cmdℹ         at <enso> case_branch(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:135:34-71)
 INFO ide_ci::program::command: cmdℹ         at <enso> Bench.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:133-136)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:134:56-66)
 INFO ide_ci::program::command: cmdℹ         at <enso> f(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Vector.enso:258:26-50)
 INFO ide_ci::program::command: cmdℹ         at <enso> go<arg-2>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:312:31-50)
 INFO ide_ci::program::command: cmdℹ         at <enso> go(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:311-313)
 INFO ide_ci::program::command: cmdℹ         at <enso> Range.fold<arg-2>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:314:13-30)
 INFO ide_ci::program::command: cmdℹ         at <enso> Range.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:308-314)
 INFO ide_ci::program::command: cmdℹ         at <enso> Vector.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Vector.enso:259:9-41)
 INFO ide_ci::program::command: cmdℹ         at <enso> case_branch(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:134:29-67)
 INFO ide_ci::program::command: cmdℹ         at <enso> Bench.fold(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:133-136)
 INFO ide_ci::program::command: cmdℹ         at <enso> Bench.run_main(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Test\2023.2.1-dev\src\Bench.enso:168-172)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(src\Main.enso:118:9-22)
 INFO ide_ci::program::command: cmdℹ         at <enso> <anonymous>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Vector.enso:723:13-26)
 INFO ide_ci::program::command: cmdℹ         at <enso> go<arg-2>(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:243:21-36)
 INFO ide_ci::program::command: cmdℹ         at <enso> go(C:\runner\_work\enso\enso\built-distribution\enso-engine-2023.2.1-dev-windows-amd64\enso-2023.2.1-dev\lib\Standard\Base\2023.2.1-dev\src\Data\Range.enso:242-244)

A new one: https://github.com/enso-org/enso/issues/8971

I think I found one not yet listed above: should be able to use external libraries if they are needed by the visualization *** FAILED *** https://github.com/enso-org/enso/actions/runs/7786527964/job/21231559557?pr=8972#step:8:2204

Another one: HttpDownloaderTest.downloadBigFileWithProgress

A new one: #9377

https://github.com/enso-org/enso/issues/9457

We fixed something. Let's close this ticket and collect new issues.

authors: 4e6 Akirathan GregoryTravis JaroslavTulach farmaazon mwu-tow radeusgd

repo: enso-org/enso


text:
Don't cancel pending visualization's upserts

Pull Request Description
Uniqueness check of UpsertVisualizationJob only involved expressionId. Apparently now GUI sends mutliple visualizations for the same expressions and expects all of them to exist. Since previously we would cancel duplicate jobs, this was problematic.
This change makes sure that uniqueness also takes into account visualization id. Fixed a few logs that were not passing arguments properly.
Closes #8801
Important Notes
I have not noticed any more problems with loading visualizations so the issue appears to be resolved with this change.
Added a unit test case that would previously fail due to cancellation of a job that upserts visualization.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

Based on the last failures I basically think that runtime/test does not attempt to recompile tests in runtime-instrument-common on which it indirectly depends on. Then no wonder it does have the required delays to simulate the problem.

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
entgql: move generate WhereInput logic to single hook

This commit isn't working, because WhereInput was failed to find CategoryConfigInput from the config.

I can't see the lint comment. Don't know why, :-/
https://user-images.githubusercontent.com/12751435/161601023-c3cb59f4-7f85-489f-8464-3c54f6b25f8f.mov

About the lint error, looks like it's about a panic:
 panic: load embedded ruleguard rules: rules/rules.go:13: can't load fmt
I had to add the code below to .golangci.yml to make it work with GO 1.18.
run:
  go: '1.18'

About the lint error, looks like it's about a panic:  panic: load embedded ruleguard rules: rules/rules.go:13: can't load fmt
I had to add the code below to .golangci.yml to make it work with GO 1.18.
run:
  go: '1.18'

Thanks, @crossworth, please feel free to contribute and fix this. I failed back to go 1.17 for now to unblock our PRs.

authors: a8m crossworth giautm

repo: ent/contrib


text:
How to calculate distance and get it?

As an additional question to the issue(https://github.com/ent/ent/issues/1833), I would also like to calculate the distance between my current location and a spot, define it as distance, and get it in ent.go.
How can I write it in that?
(Expressed in PostgreSQL, it is as follows.)
SELECT 	*,
        SQRT(
          POWER(ABS(33.6257537 - spots.latitude), 2.0) + POWER(ABS(130.446075 - spots.longitude), 2.0)
        ) as distance
FROM spots
ORDER BY (distance) ASC
LIMIT 5 OFFSET 0;

Hey @MatsuoTakuro and thanks for opening this issue.
You can use the sql/modifier API to write such queries, but note that you need to Scan the result to a custom struct. For example:
client.Spot.Query().
	Modify(func(s *sql.Selector) {
		s.AppendSelect(sql.As("SQRT(POWER(....), 2.0))", "distance"))
		s.OrderBy("distance").Limit(1)
	}).
	ScanX(ctx, &xs)

// Or:

client.Spot.Query().
	Modify(func(s *sql.Selector) {
		s.Select("*", sql.As("SQRT(POWER(ABS(....), 2.0))", "distance"))
		s.OrderBy("distance").Limit(1)
	}).
	ScanX(ctx, &xs)

Closing, but please let me know if you need additional help with that 🙏

source: gharchive/issue

repo: ent/ent


text:
How can I use the entgo.io/ent/dialect/sql to build a CASE WHEN selection?

I'm trying to do a custom value selection using CASE of a field using the entgo.io/ent/dialect/sql selector to build a manual query, but couldn't find any documentation available to do it.
Is is possible right now? If so, how can I do it?
Thanks in advance for the help!

Hey @carlos0202 👋
It looks like this question was answered by Aman: https://gophers.slack.com/archives/C01FMSQDT53/p1674063007090949
Closing, but please feel free to reopen or join our Discord community in case you need more help with this 😎


text:
Security: Make config file unreadable for others

Credentials should not be world readable, see DATA_SOURCE_NAME in /etc/sysconfig/mysqld_exporter

Hi I have completed the test, pull request is approved.

authors: AttilioGreco christophlehmann

license: MIT


text:
Minor simplification of bundles.is_acceptable

This commit changes the implementation of bundles.rego to avoid double negatives, e.g. not _is_unacceptable. Instead, the logic is implemented in the positive, i.e. `_is_acceptable. This makes the other functions that rely on this a little bit easier to read.
Resolves: #858

The improvement here is pretty minor, and somewhat subject. Happy to drop it if this is not an obvious improvement to others.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (c802c9f) 100.00% compared to head (c53b44e) 100.00%.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #865   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           89        89
  Lines         4389      4389
=========================================
  Hits          4389      4389

Files
Coverage Δ

policy/lib/bundles.rego
100.00% <100.00%> (ø)

authors: codecov-commenter lcarva

repo: enterprise-contract/ec-policies


text:
cleanup for repo merge

This gets EM to pass Envoy format checks.

/retest

repo: envoyproxy/envoy-mobile

license_source: bigquery


text:
Add oauth2 filter state/nonce support

Title: Add oauth2 filter state/nonce support
Description:
Currently, the oauth2 filter does not implement state/nonce support. in #8571, the original filter author @derekargueta noted:

one open question I have for now is the handling of state - randomly generated nonce in the 302 redirects that, when redirected back, should match the initial nonce. The caveat is that when redirected back, it is not guaranteed (if anything, highly unlikely) to land back on the same Envoy that generated the nonce. One possibility is to store it in a browser cookie (httpOnly, secure, etc.) so that when the user-agent is redirected back to Envoy, it carries that cookie with it which can be validated against the query parameter.

The OAuth RFC and threat model also note that this is an important best practice (see relevant links below).
From the OAuth threat model doc:

The client should utilize the "state" request parameter to send the
authorization server a value that binds the request to the user
agent's authenticated state (e.g., a hash of the session cookie used
to authenticate the user agent) when making an authorization request.
Once authorization has been obtained from the end user, the
authorization server redirects the end-user's user agent back to the
client with the required binding value contained in the "state"
parameter.

The binding value enables the client to verify the validity of the
request by matching the binding value to the user agent's
authenticated state.

The OAuth filter would ideally implement this, to protect against the attack described in the link. Our security team called this out as a security gap as part of considering using this filter.
Are there any issues / concerns with adding support for this, or would a patch be welcome if someone writes the code to support it?
Relevant Links:

https://datatracker.ietf.org/doc/html/rfc6819#section-5.3.5
https://www.rfc-editor.org/rfc/rfc6749#section-10.12

cc @mattklein123

Hi, any updates on this?

@alyssawilk Can you please mark this help wanted?

Hi, any updates on this? This filter is also utilized by the envoy gateway project and is most likely used in many production setups. The current insecure behavior of setting the state parameter to the request uri makes this filter unusable.

Can we use csrf filter as as workaround for this issue? We need this filter to be implemented in order to allow OIDC at Istio-Gatwaey.

/aasign

/assign

This issue can be closed because it's implemented in #35919 .

authors: andrefurlan-db bryanmcq-db prakash24 ramaraochavali wbpcode zhaohuabing

repo: envoyproxy/envoy


text:
When UUID is used for X-Request-Id, Envoy Proxy updates it but only the version number

Title: When UUID is used for X-Request-Id, Envoy Proxy updates it but only the version number.
Description:

I am using envoy 1.11.0 seeing a weird behavior where when using a UUID v4 as value for X-Request-Id field, it gets changed but only the version number. e.g if the incoming value is c2547496-4b58-4dd3-9a0a-c9ecbb621a65 after it hits the first instance of proxy, it gets converted into c2547496-4b58-9dd3-9a0a-c9ecbb621a65

xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx
mutating it to
xxxxxxxx-xxxx-9xxx-xxxx-xxxxxxxxxxxx
I have created a sample app here with instructions on how to replicate this issue:
https://github.com/a-sharma11/envoy_demo
The behavior works fine when the value itself is wrapped in quotes meaning this works fine:
curl 'http://localhost:8000/trace/1' -H 'x-request-id: "14c62072-28aa-4517-9f86-b5f9c84f20c7"'
Note the double quotes in the value.

@a-sharma11  Just want to confirm: the proper behavior is that this should work:
curl 'http://localhost:8000/trace/1' -H 'x-request-id: 14c62072-28aa-4517-9f86-b5f9c84f20c7'

is that right?

@a-sharma11 Just want to confirm: the proper behavior is that this should work:
curl 'http://localhost:8000/trace/1' -H 'x-request-id: 14c62072-28aa-4517-9f86-b5f9c84f20c7'

is that right?

YES

This is related/duplicate of https://github.com/envoyproxy/envoy/issues/7624


text:
Feature request: network quality estimator support

Title: Feature request: Network quality estimator support
Description:

For many applications, it is important to know the network quality of each client.
eg, when you watch a video on youtube, it displays different quality (1080p, 720p, 360p...), if your network quality is good, then 1080p, if weak, then 360p. This feature depends on network quality estimator. Now on client side, there are some implementations, see https://chromium.googlesource.com/chromium/src/+/master/net/nqe.

I'd like to see network quality estimator support in envoy, then, the application server side can get network quality of each client and decides which quality of the resources(videos, images) to dispatch for the given request, It will be great for the developers of the applications.

Thanks for your time to take a consideration!

[optional Relevant Links:]

Any extra documentation required to understand the issue.
Please open this URL by Chrome: https://googlechrome.github.io/samples/network-information/index.html
Example output:

         type: undefined
     downlink: 2.3Mb/s
          rtt: 100ms
  downlinkMax: undefinedMb/s
effectiveType: 4g
     saveData: false

FWIW this is something we plan on implementing in the context of Envoy Mobile. cc @junr03 @goaway

Thanks @mattklein123 for your reply.
As RTT(round trip time) is the most important metrics of network quality. I will use RTT as network quality below.
Envoy mobile run on the client side, so the client application developer should fetch RTT and then they have two choices:

Send RTT in http headers(then the server decide which quality of resource to response)
Get RTT and decide which quality of resource to GET(eg, HTTP GET /example_video_720p)

If we do network quality detecting by envoy, and then modify the http request header by adding RTT: 120ms, the client side developer need do nothing (eg HTTP GET /example_video). (The server side get the http headers and decide which quality of resource to response, without any adding work). It matchs the philosophy of envoy which says The network should be transparent to applications.
I think it will be great to the developers.
I don't deny that network quality estimator in Envoy Mobile is a good idea, but please consider that should we do it at server side.
And, another important point is, how to get RTT by Envoy, I think we can do by tcp_diag. See
$ ss -i state established '( sport = :http or dport = :http )'
Netid  Recv-Q Send-Q Local Address:Port                 Peer Address:Port
tcp    0      0         ::ffff:10.224.17.151:http                 ::ffff:10.93.247.27:59709
	 westwood wscale:6,10 rto:232 rtt:31.697/2.894 ato:40 mss:1368 cwnd:10 bytes_acked:4062 bytes_received:3303 segs_out:10 segs_in:19 data_segs_out:8 data_segs_in:8 send 3.4Mbps lastsnd:3024 lastrcv:3024 lastack:2992 pacing_rate 6.9Mbps rcv_space:28960 minrtt:29.067
tcp    0      0         ::ffff:10.224.17.151:http                 ::ffff:10.93.235.90:51914
	 westwood wscale:6,10 rto:236 rtt:32.086/9.681 ato:40 mss:1368 cwnd:10 bytes_acked:959 bytes_received:776 segs_out:3 segs_in:6 data_segs_out:2 data_segs_in:2 send 3.4Mbps lastsnd:584 lastrcv:584 lastack:552 pacing_rate 6.8Mbps rcv_space:28960 minrtt:31.043
tcp    0      0         ::ffff:10.224.17.151:http                 ::ffff:10.93.247.27:60156
	 westwood wscale:6,10 rto:232 rtt:31.98/15.99 mss:1368 cwnd:10 segs_in:2 send 5.5Kbps lastsnd:3044 lastrcv:3044 lastack:3044 pacing_rate 6.8Mbps rcv_space:28960 minrtt:31.98

And again, for some clients, eg Chrome, which accept Client hints including RTT and ECT, The only work we need to do at envoy is Intercepting the response package and adding client hints in http headers.
Accept-CH: rtt, ect
Accept-CH-Lifetime: 3600

Then chrome will report the values by adding them in their next request header. See https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints
Thanks again.


text:
wasm: update V8 to v10.0.139.6.

Signed-off-by: Piotr Sikora piotrsikora@google.com

/lgtm deps

/LGTM deps

/retest

authors: PiotrSikora wrowe


text:
build: moving rest config subscription to extensions

Risk Level: low
Testing: n/a
Docs Changes: n/a
Release Notes: inline
https://github.com/envoyproxy/envoy/issues/26450

@phlax this auto-merged with 2 broken builds.  Did your tweaks this morning remove coverage as required?
https://github.com/envoyproxy/envoy/pull/26513 fixes


text:
formatter: add two tests NaN and Infinity

https://github.com/envoyproxy/envoy/pull/26464 removed JsonOrDie function but added ENVOY_BUG in the format call path.
The pre-release version of Protobuf includes this change:
Expect fail when serialize inf and nan for Value.number_value in json format. fixes #11259
https://github.com/protocolbuffers/protobuf/commit/ca1cb1ba80ef18f5dccfb5b6ee7fa623ba6caab5
If we bump the Protobuf version, there will be an exception & crash using NaN/inf/-inf in protobuf.struct number_value when performing the serialization, while there is no check for this behavior right now.
Added 2 tests to catch this behavior change in the future.
Commit Message:
Additional Description:
Risk Level: Low
Testing: unit
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @alyssawilk


text:
Record request header processing time in downstream timings

Commit Message: Record request header processing time in downstream timings
Additional Description:
Risk Level: Low
Testing: Added unit test
Docs Changes: n/a
Release Notes: included
Platform Specific Features:
Fixes  #31064
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest

There are legit test errors in the debug builds. https://source.cloud.google.com/results/invocations/4beda602-1bd8-4b24-9e47-45b4ed373a7a
/wait

authors: fcfort yanavlasov


text:
accesslog: Restructure gRPC access log implementation

Description:

Move messaage construction and stream management to per-thread GrpcAccessLogger object
Don't silently ignore config changes and/or loggers with different configs
De-duplicate loggers based on the exact protobuf config

Risk Level: MEDIUM (logger rewrite)
Testing: updated unit tests, existing integration tests
Docs Changes: n/a
Release Notes: n/a
Updates #7674

@mattklein123 I believe comments are addressed, can you have another look, please?

@euroelessar PTAL at clang-tidy CI

Oh, fair, thanks, updated.

/azp run envoy-macos


text:
EG Dev on Mac Does Not Work with

The Dev environment for Mac with docker-mac-net-connect does not work with Docker Desktop 4.16.x due to https://github.com/docker/for-mac/issues/6699. I was able to workaround this issue by using this Docker Desktop dev build.

The docs should be updated to xref this issue.

repo: envoyproxy/gateway


text:
feat: support docs preview

fixes: https://github.com/envoyproxy/gateway/issues/1009
require two action secrets:

NETLIFY_SITE_ID
NETLIFY_AUTH_TOKEN

more usage can be found: https://github.com/nwtgck/actions-netlify

demo is here: https://github.com/Xunzhuo/gateway/pull/9

authors: Xunzhuo zirain


text:
bug: add h3 alpn by default if http3 is enabled

Fixes: https://github.com/envoyproxy/gateway/issues/2875

I don't think this is needed.
Duplicating my response from the issue:
I took a look at how https://www.cloudflare.com/ works (redacted for readability):
$ openssl s_client -connect www.cloudflare.com:443 -alpn h3,http/1.1
SSL handshake has read 4713 bytes and written 418 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE

ALPN protocol: http/1.1

Early data was not sent
Verify return code: 0 (ok)
---
HEAD / HTTP/1.1
Host: www.cloudflare.com
---
HTTP/1.1 200 OK
Date: Tue, 12 Mar 2024 06:04:10 GMT
Content-Type: text/html; charset=utf-8

alt-svc: h3=":443"; ma=86400

You can see that I offer h3 from the client as well as http/1.1 (using openssl from the CLI, so no HTTP/2 for me), and the server rejects h3 and accepts http/1.1. Later on, the alt-svc header is used to offer the h3 protocol.

I don't think this is needed.
Duplicating my response from the issue:
I took a look at how https://www.cloudflare.com/ works (redacted for readability):
$ openssl s_client -connect www.cloudflare.com:443 -alpn h3,http/1.1
SSL handshake has read 4713 bytes and written 418 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE

ALPN protocol: http/1.1

Early data was not sent
Verify return code: 0 (ok)
---
HEAD / HTTP/1.1
Host: www.cloudflare.com
---
HTTP/1.1 200 OK
Date: Tue, 12 Mar 2024 06:04:10 GMT
Content-Type: text/html; charset=utf-8

alt-svc: h3=":443"; ma=86400

You can see that I offer h3 from the client as well as http/1.1 (using openssl from the CLI, so no HTTP/2 for me), and the server rejects h3 and accepts http/1.1. Later on, the alt-svc header is used to offer the h3 protocol.

its for the case where client starts off with --http3-only similar to the knob in curl https://curl.se/docs/http3.html

its for the case where client starts off with --http3-only similar to the knob in curl https://curl.se/docs/http3.html

I took a network trace, and I think this PR went a little too far.
The h3 protocol is required on the TLS context in the QUIC listener, and not in the regular TCP listener. When using curl --http3, curl only tries to negotiate h3 on the QUIC based traffic.

@liorokman what about the http3-only case ?

When using --http3-only with curl, it means that curl will not try to open a TCP connection at all, but rather only use  QUIC over UDP. If there is no response on UDP, curl with --http3-only will simply fail.
As opposed to --http3, where curl will fallback to HTTP/2 over TCP if it doesn't get an HTTP/3 response over UDP after a short delay (e.g. 100ms).
In both cases, the TCP listener doesn't need to advertise h3 in its ALPN protocol list in the TLS context, since by definition h3 can't be used over TCP, and the QUIC listener doesn't need to advertise anything other than h3 in its ALPN protocol list, since by definition only h3 is possible over QUIC.

authors: arkodg liorokman


text:
建议增加自定义提示文案

在使用过程中, 发现默认提示文案不能满足需求, 自定义提示文案的需求比较强烈;

This seems like a dup of #74?

repo: envoyproxy/protoc-gen-validate


text:
document load-time optimizations and patterns

We need documentation and examples to demonstrate:

load order issues
pacification ('loading') screens
minification, debug vs build
lazy-creation application design
performance pitfalls

Closing out - issue quite old and not a priority to retest and assess current behavior.

authors: lishammel sjmiles

repo: enyojs/enyo


text:
运行脚本get_predict_qlora.sh的时候，如何传入模型地址

Traceback (most recent call last):
File "/root/xx/DB-GPT-Hub/predict_qlora.py", line 233, in
dataset_name, result = predict()
File "/root/xx/DB-GPT-Hub/predict_qlora.py", line 109, in predict
) = parser.parse_args_into_dataclasses()
File "/root/anaconda3/envs/dbgpt_hub/lib/python3.10/site-packages/transformers/hf_argparser.py", line 347, in parse_args_into_dataclasses
raise ValueError(f"Some specified arguments are not used by the HfArgumentParser: {remaining_args}")
ValueError: Some specified arguments are not used by the HfArgumentParser: ['--peft_ckpt_path', 'adapterqlora']

i

Traceback (most recent call last): File "/root/xx/DB-GPT-Hub/predict_qlora.py", line 233, in dataset_name, result = predict() File "/root/xx/DB-GPT-Hub/predict_qlora.py", line 109, in predict ) = parser.parse_args_into_dataclasses() File "/root/anaconda3/envs/dbgpt_hub/lib/python3.10/site-packages/transformers/hf_argparser.py", line 347, in parse_args_into_dataclasses raise ValueError(f"Some specified arguments are not used by the HfArgumentParser: {remaining_args}") ValueError: Some specified arguments are not used by the HfArgumentParser: ['--peft_ckpt_path', 'adapterqlora']

if not works , you can difine the model path in the predict_qlora.py , the function :
"
def get_args():
parser = argparse.ArgumentParser()
parser.add_argument(
"--base_model_name_or_path",
type=str,
default="/home/model_files/Llama-2-13b-chat-hf",
)
parser.add_argument(
"--peft_ckpt_path",
type=str,
default="/home/LLM/DB-GPT-Hub/llama_adapter/qlora_32_lr_2e4_drop1e1/checkpoint-500",
.....
"

authors: Matter-Charles wangzaistone

repo: eosphoros-ai/DB-GPT-Hub


text:
[Publication]: For published folder rules are available while creating publication request

EPAM AI DIAL chat version
0.12.0
How to reproduce
Preconditions:
there is folder_test1 published by user1 in root of Organization
Steps:

user2 create publication request for chat
user2 change path and select folder_test1 -> all rules are available for editing, no values in filters are displayed - > bug

Actual result
all rules are available for editing
TBD: do wee need to identify published folders which were not created inside Organization (just published from user) inside Change to form
Expected result
Users should not be able to change or assign rules for published folders
Confidential information

[X] I confirm that do not share any confidential information

not an issue

repo: epam/ai-dial-chat


text:
Error during 'annotation' bootstrap locally

During local bootstrap of annotation (with docker-compose) we have this:
annotation             | 09-Dec-22 10:33:03 - [INFO] - uvicorn.error - (server.py).serve(84) - Started server process [9]
annotation             | INFO:     Waiting for application startup.
annotation             | 09-Dec-22 10:33:03 - [INFO] - uvicorn.error - (on.py).startup(45) - Waiting for application startup.
annotation             | 09-Dec-22 10:33:13 - [WARNING] - kafka.conn - (conn.py).dns_lookup(1527) - DNS lookup failed for kafka:9092, exception was [Errno -3] Temporary failure in name
resolution. Is your advertised.listeners (called advertised.host.name before Kafka 9) correct and resolvable?
annotation             | 09-Dec-22 10:33:13 - [ERROR] - kafka.conn - (conn.py)._dns_lookup(315) - DNS lookup failed for kafka:9092 (AddressFamily.AF_UNSPEC)
annotation             | 09-Dec-22 10:33:13 - [INFO] - kafka.conn - (conn.py).check_version(1205) - Probing node bootstrap-0 broker version
annotation             | 09-Dec-22 10:33:23 - [WARNING] - kafka.conn - (conn.py).dns_lookup(1527) - DNS lookup failed for kafka:9092, exception was [Errno -3] Temporary failure in name
resolution. Is your advertised.listeners (called advertised.host.name before Kafka 9) correct and resolvable?
annotation             | 09-Dec-22 10:33:23 - [ERROR] - kafka.conn - (conn.py)._dns_lookup(315) - DNS lookup failed for kafka:9092 (AddressFamily.AF_UNSPEC)
annotation             | 09-Dec-22 10:33:23 - [WARNING] - app.logger - (main.py)._init_search_annotation_producer(957) - Error occurred during kafka producer creating: NoBrokersAvailab
le
annotation             | INFO:     Application startup complete.
The app tries to find kafka, but doesn't find it

Duplicate: #460

authors: khyurri spiridonovfed

repo: epam/badgerdoc


text:
Initializer from endpoint specs directory

The initializer for SapiClient Application currently takes a path to the sapi-nt application.yml configuration file
This YAML file is parsed and the sapi-nt.config.loadSpecPath path is read, any classpath ignored and the resulting directory used to find all endpoint configuration YAML files used to create proxy Ruby classes and methods.
See https://github.com/epimorphics/sapi-client-ruby/blob/main/lib/sapi_client/application.rb
In order to separate out these endpoint configuration files, we would like to provide a way to initialize the SapiClient Application directly with this spec path directory.
Proposal: keep backward compatibility by still allowing a path to application.yml; check whether the path is a directory or file; if a directory, just use directly for endpoint_group_files.

I'm marking this as fixed as the test suite includes parallel checks for initializing with the endpointSpecs directory. The functionality still needs to be tried out as part of epimorphics/fsa-rpa-api#13.

repo: epimorphics/sapi-client-ruby


text:
Investigate if creation of custom services after upgrades with the same name should be allowed

Context.
I created in v.1.3.0 a custom service named mycustom-service and bound to an app testapp . The hash for this version is x5dc8835923fe6cac2053d8aa18b1-mysql
I upgrade to v.1.4.0 and create the same service with hash for v.1.4.0: x8e5ee833a0f2faebaf5c4171baca-mysql
When I try to bump a second app, testapp2 it is bound to both services:
🚢  Listing configurations
Namespace: workspace

✔  Epinio Configurations:
|                NAME                 |            CREATED            |  TYPE   |      ORIGIN      |   APPLICATIONS    |
|-------------------------------------|-------------------------------|---------|------------------|-------------------|
| x5dc8835923fe6cac2053d8aa18b1-mysql | 2022-11-10 09:03:51 +0100 CET | service | mycustom-service | testapp, testapp2 |
| x8e5ee833a0f2faebaf5c4171baca-mysql | 2022-11-10 10:04:21 +0100 CET | service | mycustom-service | testapp2          |
➜  epinio git:(main) epinio service list

🚢  Listing Services...
Namespace: workspace

✔  Details:
|       NAME       |            CREATED            | CATALOG SERVICE | VERSION |  STATUS  |   APPLICATIONS    |
|------------------|-------------------------------|-----------------|---------|----------|-------------------|
| mycustom-service | 2022-11-10 10:04:19 +0100 CET | mysql-dev       | 8.0.29  | deployed | testapp, testapp2 |
| mycustom-service | 2022-11-10 09:03:46 +0100 CET | mysql-dev       | 8.0.29  | deployed | testapp, testapp2 |

Thanks. Confirmed, without having to bind the services to applications.
Just creating them with 1.3.0 and 1.4.0 is enough.
The 1.3.0 service consists of an helm chart spec in the epinio namespace, and a helm release in the target space.
Trying to create two services of the same name fail on the duplicate helm chart spec
The 1.4.0 service consists of a secret in the target namespace, and a helm release in the same. With a different derivation of the name.
Trying to create two services of the same name fail on the duplicate secret.
Doing a two services with 1.3.0, and 1.4.0 they pass each other on the first (spec vs secret) and the helm release have different names due to the different derivations, so no clash there either.
The 1.4.0 validation of services has to be changed to properly recognize 1.3.0 services as well.
And better do it explicitly instead of having a creation op fail on the lower-level resource (helm chart spec, secret).

repo: epinio/epinio


text:
[UI] - Using manifest file with a configuration should bind it by default

When I was testing latest UI, I played with the manifest feature and something surprised me.
I have a manifest file which contains a configuration (conftest):
{"name":"manifesttest","configuration":{"instances":2,"configurations":["conftest"],"environment":{"tes1":"tee3","tret":"tert"},"routes":["manifesttest.172.18.0.2.omg.howdoi.website"],"appchart":"standard"},"origin":{"Kind":1,"git":{"repository":""},"path":"sample-app.tar.gz"}}%

Then I created an app and import this manifest file, no configuration was bound by default:

If you want the configuration, you have to click on it:

I was expecting that the configuration would be automatically selected.
:warning: However, even if you do not select it, the configuration is bounded anyway, maybe just a display thing to fix/improve.

Checked on epinio-dev and working.
Showing here differences before/after on this video:
https://user-images.githubusercontent.com/37271841/218967152-31891ecd-e59f-4a90-b54b-00487f20f40e.mov

repo: epinio/ui


text:
[BUG] Only 32 GB mounted on the root directory when the disk size of the repository machine is 64 GB

Describe the bug
The root partition shows only 32 GB mounted on "/" when the disk size is 64 GB (applies to Azure/RedHat configuration).
To Reproduce
Deploy a new cluster from develop branch with the configuration given below: epicli apply -f test.yml
Config files
...
  components:
    kafka:
      count: 0
    kubernetes_master:
      count: 0
    kubernetes_node:
      count: 0
    load_balancer:
      count: 0
    logging:
      count: 0
    monitoring:
      count: 0
    postgresql:
      count: 0
    rabbitmq:
      count: 0
    ignite:
      count: 0
    opendistro_for_elasticsearch:
      count: 0
    repository:
      count: 1
      machine:  repository-machine-rhel
---
kind: infrastructure/virtual-machine
name: repository-machine-rhel
provider: azure
based_on: repository-machine
specification:
  storage_image_reference:
    publisher: RedHat
    offer: RHEL
    sku: 7-RAW
    version: 7.7.2019090418

Expected behavior
There should be ~64GB available mounted on a root directory.
OS (please complete the following information):

OS: [RHEL7]

Cloud Environment (please complete the following information):

Cloud Provider [MS Azure]

Additional context
[operations@ci-devazurrhelcanal-repository-vm-0 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.7G     0  1.7G   0% /dev
tmpfs           1.7G     0  1.7G   0% /dev/shm
tmpfs           1.7G  9.1M  1.7G   1% /run
tmpfs           1.7G     0  1.7G   0% /sys/fs/cgroup
/dev/sda2        32G  4.1G   28G  13% /
/dev/sda1       497M  101M  397M  21% /boot
/dev/sdb1       6.8G  2.1G  4.4G  32% /mnt/resource
tmpfs           345M     0  345M   0% /run/user/1000

It looks like if we have a 64 GB disk, we need to additionally resize the partition and the filesystem with fdisk and xfs_growfs.
After resizing it is OK.
[root@ci-devazurrhelcanal-repository-vm-0 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.7G     0  1.7G   0% /dev
tmpfs           1.7G     0  1.7G   0% /dev/shm
tmpfs           1.7G  9.1M  1.7G   1% /run
tmpfs           1.7G     0  1.7G   0% /sys/fs/cgroup
/dev/sda2        64G   16G   48G  25% /
/dev/sda1       497M  101M  397M  21% /boot
/dev/sdb1       6.8G   32M  6.4G   1% /mnt/resource
tmpfs           345M     0  345M   0% /run/user/1000

From configuration perspective it looks all good. For other scenarios (non Azure/RHEL it does not occur).
Hold on until introducing lvm.

This might be solved by #1355. It should be checked again after another one is closed.

This might be solved by #1355. It should be checked again after another one is closed.

Summary:

The task can be closed, the main issue resolved by #1355.
Additional output of the task is the bug: #2098.

repo: epiphany-platform/epiphany


text:
Option "errors" must be boolean

Fixing problem of "custom keyword definition is invalid: data.errors should be boolean".
Ex. issue in webpack:
https://github.com/webpack/webpack/issues/8768

Coverage remained the same at 100.0% when pulling 0a631d33dc1d7993d8ce7a9e1761b50407f2ee9c on DarkLink363:patch-1 into 5d134394acb6429840438cc262c36c76d91e356c on epoberezkin:master.

It's fixed in ajv 6.9.1 - please update

authors: DarkLink363 coveralls epoberezkin

repo: epoberezkin/ajv-errors

license: mit


text:
fix: For Resetting always-pxe flag

Description :
This PR  fixes the issue https://github.com/equinix/metal-cli/issues/257

This seems to be working as expected with explicit --always-pxe definitions appearing in the request for update. On create, however, I only see explicit request body for enabling always-pxe.  This is fine because the default behavior is false. I suspect we have an omit-empty in the create request, but even if that's not the case - this is fine.
$ PACKNGO_DEBUG=1 go run ./cmd/metal device create --always-pxe=false
2023/10/18 17:00:34
POST /metal/v1/projects/projectid/devices HTTP/1.1
Host: api.equinix.com
User-Agent: metal-cli/(devel) metal-go/0.25.0
Content-Length: 188
Accept: application/json
Content-Type: application/json
X-Auth-Token: foo
Accept-Encoding: gzip

{"billing_cycle":"hourly","customdata":{},"hostname":"foo","metro":"sv","operating_system":"alpine","plan":"c3.small.x86","spot_instance":false,"spot_price_max":0,"tags":[],"userdata":""}

authors: displague vasubabu

repo: equinix/metal-cli


text:
[Bug]: Assets for v1.25.0 Release Not Found

Terraform Version
v1.3.7
Equinix Provider Version
version="1.25.0"
Effected Terraform Resources
No response
Terraform Config Files
No response
Debug Output
There seem to be some issues with the release of version 1.25.0 of the equinix/equinix package. The build output assets are clearly missing, and an error occurs when executing terraform init, indicating a 404 error.

Panic Output
No response
Expected Behavior
The expected behavior is to be able to successfully retrieve the provider for version v1.25.0.
Actual Behavior
The assets related to version v1.25.0 cannot be found.
Steps to Reproduce
$ cat test/provider.tf
terraform {
  required_providers {
    equinix = {
      source = "equinix/equinix"
      version = "1.25.0"
    }
  }
}

provider "equinix" {
  # Configuration options
}

$ terraform -chdir="test" init

The release artifacts for v1.25.0 were accidentally deleted after release.  We have released v1.25.1, which is identical to v1.25.0 but has a different version number because republishing provider release artifacts after they have been deleted or corrupted causes SHA mismatch errors.

authors: ErikJiang ctreatma

repo: equinix/terraform-provider-equinix


text:
Error when creating top level routes

It seems like we are not able to create a top level route.
This was discovered by the German satellite site team, and I have tested and found the same on dev and in production.
The German site is launching a campaign late next week and need a new top level route for their campaign material.
Private Zenhub Image

Thanks @millianapia - this works now, approved :smile:

repo: equinor/energyvision


text:
Relate more to data.content in the explorer

The data.content tag is quite central, and is actively white-listed and standardized through fmu-dataio. However, the explorer does not relate much to it. It does, however, have some knowledge about the data.tagname property which can be problematic down the line.

No standard on data.tagname, its main purpose is to provide unique filenames on the disk
Each asset will have their personal customized way of setting "tagname", so no logic can be built on the tagname. A key purpose with the new data standard - and Sumo - is to enable scalable data consumption.
If applications such as Webviz start using logic on data.tagname we are recreating the current problems, and even possibly making them worse.

Refinement 30.10.2023:

PR to fmu-dataio with Eclipse data types.
Explorer examples in readme: check that they work and fix
Verify: can Explorer filter on content?
Explorer: add method for more "advanced" filtering. User specifies path to properties. (Something like ExcludeIf or Require/NotRequire?)
Explorer: enable going from case -> content -> data. ContentCollection?

authors: equinor-ruaj perolavsvendsen

repo: equinor/fmu-sumo


text:
Wrong color for camel cased constants

Hello,
I came across this strange bug in PHP.
Camel cased constants have a different colour than regular constants.

VSCode version: 1.2.0
Extensions: All disabled except for the latest Material Theme version
Settings: All set to default

It's ok with other colour themes so it can't be expected behaviour. Any ideas?

I will investigate. Right now i have no idea about the cause.

Hi @TitasGailius I found a little bug (i think) in the php extension. It provide a different scopes:
The first one is recognised as support class

The second one is recognised as "other constant"

I can only set the color for "other.constant" scopes, but this will afflict all the other variables.

I see developers use these scopes for PHP classes, do you think it might be a solution?
{
    "name": "Library class/type",
    "scope": [
        "support.type",
        "support.class"
    ],
    "settings": {
        "foreground": "#FFCB6B"
    }
},
{
    "name": "User-defined constant",
    "scope": [
        "constant.character",
        "constant.other"
    ],
    "settings": {
        "foreground": "#FFCB6B"
    }
},

The issue is that i have two completely different scopes. I can't make the camelcase one yellow, because use the same scope of other variables. I can only make grayish the not camelcase one.

Yeah, making it grey-ish is a solution and maybe it's even a better one because it makes it easier to differentiate classes from constants although that's not how most themes that I've used behave.
For my personal liking, I wanted it to be consistent so I added this override to my vs-code config which perfectly solves the issue:
    "editor.tokenColorCustomizations": {
        "textMateRules":[
            {
                "scope": "constant.other.php",
                "settings": {
                    "foreground": "#FFCB6B"
                }
            }
        ]
    }

@TitasGailius In your config you are changing the color of the second one, not the first one.

Yes, I know.
What I meant is that from my experience on how other themes behave and for my personal liking I wanted it to be yellow as it's more consistent. :)

Ok, I think I can release a fix with yellow constant.other.php.

Fixed in the new release

authors: TitasGailius equinusocio

repo: equinusocio/vsc-material-theme


text:
No type assigned to deliveryPointCode property

https://github.com/erasmus-without-paper/ewp-specs-types-address/blob/5904a9878653ceba0ce23466e4408a49eb383932/schema.xsd#L159

Thanks for noticing!

authors: casualtimer mkurzydlowski


text:
Display problem in K0178.xml

code: kantrum<unclear>·</unclear><g type="circleMed">.</g> niya<choice><sic>n</sic><corr>m</corr></choice>a
display:

Can you sort this out @ajaniak ?

Dear @chloechollet,
I am not sure what you want me to sort. Is it the fact that the <g type="circleMed">.</g> is displayed as |?

Dear @chloechollet,
I am not sure what you want me to sort. Is it the fact that the <g type="circleMed">.</g> is displayed as |?

we are seeing not (·)| but (·| in the display on our side — generated with XLST in Oxygen.
[cid:6F1A560A-0F26-40C4-8BAA-0C94C87210C4@home]
display on your side is different!
Le 19 janv. 2021 à 16:12, ajaniak <notifications@github.commailto:notifications@github.com> a écrit :
Dear @chloechollethttps://github.com/chloechollet,
I am not sure what you want me to sort. Is it the fact that the . is displayed as |?
[Capture d’écran 2021-01-19 à 16 10 40]https://user-images.githubusercontent.com/33328906/105053136-e9c87e80-5a70-11eb-93ff-360ec29ae1c3.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/erc-dharma/tfc-khmer-epigraphy/issues/20#issuecomment-762905608, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGMAE5O7VHJRBITXL7H5KDS2WOPRANCNFSM4WI43Y7A.

we are seeing not (·)| but (·| in the display on our side — generated with XLST in Oxygen.
[cid:6F1A560A-0F26-40C4-8BAA-0C94C87210C4@home]
display on your side is different!
Le 19 janv. 2021 à 16:12, ajaniak <notifications@github.commailto:notifications@github.com> a écrit :
Dear @chloechollethttps://github.com/chloechollet,
I am not sure what you want me to sort. Is it the fact that the . is displayed as |?
[Capture d’écran 2021-01-19 à 16 10 40]https://user-images.githubusercontent.com/33328906/105053136-e9c87e80-5a70-11eb-93ff-360ec29ae1c3.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/erc-dharma/tfc-khmer-epigraphy/issues/20#issuecomment-762905608, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGMAE5O7VHJRBITXL7H5KDS2WOPRANCNFSM4WI43Y7A.

Do you have the last version of the XSLT on your computer?
My version of the output as well as the automated html are both with (·)|  and checking the codes history, this issue should have been resolved with the commit made the 4/11/2020.

Do you have the last version of the XSLT on your computer?
My version of the output as well as the automated html are both with (·)|  and checking the codes history, this issue should have been resolved with the commit made the 4/11/2020.

My bad. I’ve just done a git pull on project-documentation and the problem seems to have been resolved on the new html version.

My bad. I’ve just done a git pull on project-documentation and the problem seems to have been resolved on the new html version.

authors: ajaniak arlogriffiths chloechollet

repo: erc-dharma/tfc-khmer-epigraphy


text:
Add a new limiter for the VOS equation

Adds a conservative global limiter for volume fractions that have a physical min/max. Also fixes up and refactors the VOF/VOS code.
/cc @manuel-quezada

I think we should add the implosion tests for the VOS model.

@manuel-quezada sounds good on adding the implosion tests. See @adimako 's question about the old VOF/LS/VOS. It was my understanding that the old approach will still work and continue to be supported.

authors: cekees manuel-quezada

repo: erdc/proteus


text:
Switching to libsass using Grunt

I've been using susy with grunt. After seeing the release of susy 2.2.2 with libsass support I went straight to setting it up but I can't get it running.
I've seen other problems people have had, mainly due to @include path. When I first ran grunt with the grunt-sass, susy set-up I didn't change the import path so I got errors saying that the file couldn't be found. I changed the import path to go direct to susy in my projects node_modules folder. I ran my grunt task again and instead of getting the previous error of 'no file found' I got an 'invalid property' error.
I'm a bit stuck here as It seems like the correct path is in place due to the no file found error going away, but the susy file doesn't seem to be loading as mixins aren't there.
I have grunt, sass, libsass and susy in their latest version the sass task is as the susy documentation.
Is there anything else other than the import path that I could be getting wrong?

Can you paste in the relevant bits of code, and file structure? It's hard to comment in the abstract.

Apologies, was late and in a rush.
Sure, of course.
My Gruntfile sass task
`sass: {
    compile: {
        options: {
            require: 'susy',
            style: 'expanded',
            sourcemap: 'none',
            loadPath: require( 'node-bourbon' ).includePaths
        },
        files: [{
            'style.css': 'style.scss',
        }]
    }
}`

My package.json
"devDependencies": {     "grunt": "~0.4.5",     "grunt-sass": "~0.17.0",     "susy": "^2.2.2-alpha.1"   },
File structure
/node_modules/susy
/node_modules/grunt-sass
/sass/_partials.scss
style.scss
style.css

ok, I'm not a Grunt expert by any means, but that all makes sense to me (though you could upgrade to the 2.2.2 stable release if you want). What does you include line look like, and what's the full error message?

Unfortunately neither am I.
And thanks, I planned to upgrade asap.
Import path in style.scss and the following is in _partials.scss
@import 'node_modules/susy/sass/susy';
@import '../node_modules/susy/sass/susy';
I can't re-create the error right now, but compiling throws an error at the first @mixinit gets too. I've taken that particular mix-in out to test, and it just throws an error on the next @mixin it finds. The error is 'invalid property'.

Works great for me. I'm using latest 2.2.2 and Grunt Sass 0.17.0.
I believe ../node_modules/susy/sass/susy should be the correct file path based on your directory structure above. So you should remove that first @import in your _partials.scss

Thanks for your input @ellm. I've no doubt that the build works perfectly. I've tried everything except starting from scratch which I can't do right now, I assume there is something in my set-up causing this issue now.
Thanks @ericam

I noticed that you are using "loadPath" for Bourbon whereas LibSass uses "includePaths".  That could also be one of the culprits for errors if you are still getting them.
e.g.
includePaths: require('node-bourbon').includePaths

Thanks Danny, I changed "loadPath" to "includePaths" but still the same thing happens. I know I have the correct paths in my .scss files. I'll report my solution when I get the time to find one.

authors: StudioMomentum danny-englander ellm ericam j-mccarthy

repo: ericam/susy


text:
Use fully qualified base image name for dev-env

Relates to #134
Summary
Improve compatibility of the Containerfile with non-Docker engines.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (170e8c9) 98.57% compared to head (7ddbd98) 98.57%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #186   +/-   ##
=======================================
  Coverage   98.57%   98.57%
=======================================
  Files           4        4
  Lines         140      140
=======================================
  Hits          138      138
  Misses          2        2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter ericcornelissen


text:
Clean up / Improve the list of collectors

Currently, the enabled collectors for a system lives in a static list called PLATFORM in main.rs. This is probably not the best way to gather which collectors should be run, as it would require recompilation to configure which collectors should be run.
There likely should be some kind of hybrid solution: a compile-time method to gather all the collectors available for the target arch this is compiled for (that is, perhaps an automatic way that would not require maintaining a list), and then also a run-time method to filter appropriate collectors.

better detailed in #20

repo: erichte-ibm/conga


text:
Cannot install / running

here's the output

Okay I updated nodejs and it is fixed now


text:
Unnecessary rerenders after update to 8.1.0 from 7.4.2

Are you submitting a bug report or a feature request?
Bug Report
What is the current behavior?
In 8.1.0 each field is rerendered with user input to any field.

What is the expected behavior?
Works as expected in 7.4.2.

Sandbox Link
https://redux-form.com/8.1.0/examples/simple/
https://redux-form.com/7.4.2/examples/simple/

This is probably caused by react-redux@6.0.0: https://github.com/reduxjs/react-redux/issues/1164

Note that in version 6.0, the wrapper components generated by connect() do their update work in render().  That means that they will re-render, even if your own component does not.
I've seen a couple other people report that the on-screen indicators seem to be flashing all the time.  But, use of the React DevTools Profiler indicated that it was really only the specific connected components that were updating.

authors: aizerin markerikson petrjaros

repo: erikras/redux-form


text:
Avoid leaving a reference in chunked()

Re: Issue #13, this PR modifies chunked() in order to make garbage collection of retrieved chunks possible. The method comes from @piskvorky's code. See also my comments re: performance.
I couldn't get sys.getrefcount() to show me that there was a difference, but maybe someone else has an idea for how to test?

Superseded by PR #82.

repo: erikrose/more-itertools


text:
[JS] Expecting array from tuple result

In 0.12 : take contract
contract Test {

    function getAddress() returns (address) {
      return this;
    }

    function getNumber() returns (uint) {
      return 100;
    }

    function getCombination() returns (uint _number, address _address) {
      _number = 100;
      _address = this;
    }

}

and code :
contractAPI.getCombination(function(err, data) {
  if(err){
    console.log(err);
  } else {
    console.log("getCombination : " + data);
  }
})

This returns :
getCombination : 00000000000000000000000000000000000000000000000000000000000000640000000000000000000000006A4546A31DD91AD3E5CE01C4E796680A5D32701B

I would expect it to return an array, data[0] -> 64, data[1] -> address

Have you tried adding constant at the getCombination function? see issue #46

Yep, thats it, when using constant the array is returned as expected, and the address is again preceded with '0x'.
New result with contract :
contract Test {
    function getAddress() constant returns (address) {
      return this;
    }
    function getNumber() constant returns (uint) {
      return 100;
    }
    function getCombination() constant returns (uint _number, address _address) {
      _number = 100;
      _address = this;
    }
}

and code :
contractAPI.getAddress(function(err, data) {
  if(err){
    console.log("ERROR");
    console.log(err);
  } else {
    console.log("getAddress : " + data);
  }
})
contractAPI.getNumber(function(err, data) {
  if(err){
    console.log(err);
  } else {
    console.log("getNumber : " + data);
  }
})

contractAPI.getCombination(function(err, data) {
  if(err){
    console.log(err);
  } else {
    console.log("getCombination : " + data[0] + ":" + data[1]);
  }
})

returns :
getAddress : 046B812E690E4CB54281CC469A087B0E15089EAC
getNumber : 100
getCombination : 100:0x046B812E690E4CB54281CC469A087B0E15089EAC

expected :
getAddress : 046B812E690E4CB54281CC469A087B0E15089EAC
getNumber : 100
getCombination : 100:046B812E690E4CB54281CC469A087B0E15089EAC

also without using constant.. Thanks @nottherealbatman

Fixed in 0.15.5.

authors: NodeGuy nottherealbatman rguikers


text:
Added an option to sort_link to hide the order indicator

You can now pass ":no_order_indicator => true" to sort_link parameters, so the ▲ and ▼ elements would be hidden.
Cheers ;)

+1

I it would like this, i try remove the arrows but i can't. Someone have a trick?

+1

I found a bug, i agree with option to remove the arrows from style, but the class asc and desc should remain because maybe  need for external stylesheet to use personal arrows.
Can you do that?
Good work.

authors: momolog nuc-gr skarface

repo: ernie/ransack


text:
Dependency management tool like dep can be used to manage dependencies

Instead of pushing the entire vendor folder, some dependency management tool like dep can be used. This will reduce the overhead of pushing the vendor folder every time a new external library is used.

Vendor folder is added to git because it makes it easier to build the project without dependency management tools. There are several reasons, for and against it, but I've chosen to add it to the project.

In a slow network environment, it takes a very long time to complete the vendor directory. Especially in China mainland, usually, it's 10KiB/s. In my opinion, it's better to use dep to avoid repeated downloads.

repo: erroneousboat/slack-term


text:
Reference mdbx4s in the bindings table

Hi @erthink
I have just pushed on Github a new libmdbx binding targetting the Scala platform: https://github.com/david-bouyssie/mdbx4s
It is building on the JVM (by wrapping Castotech MDBXJNI) and on Scala Native (using direct binding to the libmdbx library).
It's not yet on Maven Central bu the Github Workflow CI is green :)

Waiting until tests be done without any issues.

Done :)

authors: david-bouyssie erthink

repo: erthink/libmdbx


text:
Support eslint-plugin-vue's disable comments

In Vue Single File Components (*.vue files), "HTML comments" can be used to disable ESLint rules: https://eslint.vuejs.org/rules/comment-directive.html
<template>
  <!-- eslint-disable-next-line vue/max-attributes-per-line -->
  <div a="1" b="2" c="3" d="4" />
</template>

Unfortunately, those comments are not detected by eslint-plugin-eslint-comments.
(Note: This issue is the same as #136, which was auto-closed as stale without a warning, but is still relevant.)

This applies to CSS linting in Vue too, by the way.
<template></template>

<style module>
// eslint-disable-next-line vue-scoped-css/require-selector-used-inside
.unused {
  filter: brightness(0);
}
</style>

This should warn of the missing comment.

authors: FloEdelmann GrantGryczan