text:
[Bug] Using Firestore's offline persistence on certain Android devices causes the app to force close.

[REQUIRED] Please fill in the following fields:

Unity editor version: 2022.3.20f1
Firebase Unity SDK version: 11.6.0
Source you installed the SDK: Unity Package Manager
Problematic Firebase Component: Firestore
Other Firebase Components in use: None
Additional SDKs you are using: None
Platform you are using the Unity editor on: Mac
Platform you are targeting: Android
Scripting Runtime: IL2CPP

[REQUIRED] Please describe the issue here:
* Tinno - FIH Foxconn
    * M10
* Innovatech - Unisoc
    * T30
* Worldchip - Windriver
    * P25_T_ROW
    * P25_T_EEA
    * P80T_ROW
* Deejoy - FIH Foxconn
    * Kids_10
    * PlimPad_P3_Pro

On the above Android device, calling FirebaseFirestore.Collection, then closing the app, then starting the app again and calling FirebaseFirestore.Collection, the following error occurs and the app is forced to close.
FATAL EXCEPTION: main
Process: com.XXXX.YYYY, PID: 9713
java.lang.RuntimeException: Internal error in Cloud Firestore (24.8.1).
	at com.google.firebase.firestore.util.AsyncQueue.lambda$panic$3(AsyncQueue.java:545)
	at com.google.firebase.firestore.util.AsyncQueue$$ExternalSyntheticLambda3.run(Unknown Source:2)
	at android.os.Handler.handleCallback(Handler.java:938)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:201)
	at android.os.Looper.loop(Looper.java:288)
	at android.app.ActivityThread.main(ActivityThread.java:7876)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1182)
Caused by: java.lang.RuntimeException: android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5 SQLITE_BUSY)
	at com.google.firebase.firestore.util.AsyncQueue$SynchronizedShutdownAwareExecutor.lambda$executeAndReportResult$1(AsyncQueue.java:333)
	at com.google.firebase.firestore.util.AsyncQueue$SynchronizedShutdownAwareExecutor$$ExternalSyntheticLambda0.run(Unknown Source:4)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:487)
	at java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:307)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
	at com.google.firebase.firestore.util.AsyncQueue$SynchronizedShutdownAwareExecutor$DelayedStartFactory.run(AsyncQueue.java:235)
	at java.lang.Thread.run(Thread.java:1012)
Caused by: android.database.sqlite.SQLiteDatabaseLockedException: database is locked (code 5 SQLITE_BUSY)
	at android.database.sqlite.SQLiteConnection.nativeExecute(Native Method)
	at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:709)
	at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:325)
	at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:300)
	at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:624)
	at android.database.sqlite.SQLiteDatabase.beginTransactionWithListener(SQLiteDatabase.java:587)
	at com.google.firebase.firestore.local.SQLitePersistence.runTransaction(SQLitePersistence.java:211)
	at com.google.firebase.firestore.local.SQLiteOverlayMigrationManager.buildOverlays(SQLiteOverlayMigrationManager.java:46)
	at com.google.firebase.firestore.local.SQLiteOverlayMigrationManager.run(SQLiteOverlayMigrationManager.java:42)
	at com.google.firebase.firestore.local.LocalStore.start(LocalStore.java:182)
	at com.google.firebase.firestore.core.ComponentProvider.initialize(ComponentProvider.java:156)
	at com.google.firebase.firestore.core.FirestoreClient.initialize(FirestoreClient.java:296)
	at com.google.firebase.firestore.core.FirestoreClient.lambda$new$0$com-google-firebase-firestore-core-FirestoreClient(FirestoreClient.java:114)
	at com.google.firebase.firestore.core.FirestoreClient$$ExternalSyntheticLambda1.run(Unknown Source:8)
	at com.google.firebase.firestore.util.AsyncQueue.lambda$enqueue$2(AsyncQueue.java:444)
	at com.google.firebase.firestore.util.AsyncQueue$$ExternalSyntheticLambda6.call(Unknown Source:2)
	at com.google.firebase.firestore.util.AsyncQueue$SynchronizedShutdownAwareExecutor.lambda$executeAndReportResult$1(AsyncQueue.java:330)
	... 8 more

Firestore offline data persistence behavior not available on the aforementioned Android devices.
Steps to reproduce:

Add a Firebase project to be able to use "Cloud Firestore".
Create a new Unity project, set "Package Name" and add "google-services.json".
Add the following Firebase SDKs from the Unity Package Manager.

com.google.external-dependency-manager-1.2.177.tgz
com.google.firebase.app-11.6.0.tgz
com.google.firebase.firestore-11.6.0.tgz

Add the following script to your Unity project and attach it to the game objects in your scene.using System.Threading.Tasks;
using Firebase;
using Firebase.Firestore;
using UnityEngine;

internal sealed class Example : MonoBehaviour
{
    private async Task Start()
    {
        await FirebaseApp.CheckAndFixDependenciesAsync();
        var firebaseFirestore = FirebaseFirestore.DefaultInstance;
        firebaseFirestore.Collection( "hoge" );
    }
}

Build the application to the aforementioned Android device.
When the call to firebaseFirestore.Collection is complete, exit the application.
Start the app and wait for the firebaseFirestore.Collection call to complete.
An error occurs and the application is forcefully terminated (100%).

Supplement

Forced termination does not occur on any device other than the aforementioned Android devices.
If PersistenceEnabled is set to false as follows, no forced termination occurs.using System.Threading.Tasks;
using Firebase;
using Firebase.Firestore;
using UnityEngine;

internal sealed class Example : MonoBehaviour
{
    private async Task Start()
    {
        await FirebaseApp.CheckAndFixDependenciesAsync();
        var firebaseFirestore = FirebaseFirestore.DefaultInstance;
        firebaseFirestore.Settings.PersistenceEnabled = false;
        firebaseFirestore.Collection( "hoge" );
    }
}

Unfortunately, Firestore has had ongoing issues with SQLiteDatabaseLockedException exceptions being thrown in Android that we have not been able to fully understand, reproduce, or resolve. Here are some examples: https://github.com/search?q=repo%3Afirebase%2Ffirebase-android-sdk+SQLiteDatabaseLockedException&type=issues
Since it sounds like you can consistently reproduce this issue, could you do the following to assist with our investigation:

Set FirebaseFirestore.LogLevel = LogLevel.Debug as early as possible in your application.
Reproduce the crash.
Capture the Android logcat log.
Post the captured logcat log to https://gist.github.com/ and include the link to the gist in a comment on this issue.

The logcat log with debug logging enabled will provide a great deal of information to help focus the investigation.
Thank you for reporting this issue.

Thanks for the reply!

Set FirebaseFirestore.LogLevel = LogLevel.Debug as early as possible in your application.

using System.Threading.Tasks;
using Firebase;
using Firebase.Firestore;
using UnityEngine;

internal sealed class Example : MonoBehaviour
{
    private async Task Start()
    {
        await FirebaseApp.CheckAndFixDependenciesAsync();
        FirebaseFirestore.LogLevel = LogLevel.Debug; // Add
        var firebaseFirestore = FirebaseFirestore.DefaultInstance;
        firebaseFirestore.Collection( "hoge" );
    }
}

I have changed the script as above.

Reproduce the crash.
Capture the Android logcat log.
Post the captured logcat log to https://gist.github.com/ and include the link to the gist in a comment on this issue.

The Android logcat log of the crash is attached below.
https://gist.github.com/baba-s/d8fb4309fcdaa73b51e80ea6798ecdad
Also, if firebaseFirestore.Collection is called when the app is first launched, it will not crash, so the log of that call is also attached below.
https://gist.github.com/baba-s/4faedc5796397b1d553782173986fe1f

Since it sounds like you can consistently reproduce this issue

Yes, I have an Android device that can reproduce the crash 100%.
I hope this helps.

Thanks for the logs! It looks like you've gone through the trouble to capture the exact logs output by your application. I'm actually interested in the entire device logs, even though they will be noisy. I'm especially interested if the "successful" launch of your application has the same linux PID as the instance that encounters the exception and, if not, if there is some overlap of their lifetimes.
If possible, could you redo this experiment with some modifications to the steps:

From your computer, run adb logcat -c to clear the logcat logs.
Run adb logcat -c again (sometimes the first run doesn't actually clear the logs :shrug:)
Run adb logcat >capture.logcat.txt and let it continue running.
Launch your application successfully.
Launch your application again, in the way that reproduces the crash.
Press CTRL+C on your computer to end the logcat capture started in step 3.
Upload capture.logcat.txt to a GitHub Gist.

It would also be interesting to see a screen recording of the Android device of you following the reproduction steps above. To do that, follow these steps:

From your computer, run adb shell screenrecord --bugreport /data/local/tmp/screenrecord.mp4
Follow the steps in the previous paragraph to capture the logcat.
Press CTRL+C on your computer to end the screen recording.
Run adb pull /data/local/tmp/screenrecord.mp4 to copy the video from the Android device to your computer.
Upload the video screenrecord.mp4 to the Internet somewhere and attach a link to it (you may be able to drag-and-drop it into this GitHub issue comment).

If you could do one or both of these it could help a lot. Thanks!

Hi, I have taken the following steps to log based on the instructions you gave me. 🙇

Run adb logcat -c.
Run adb logcat -c again.
Run adb logcat >capture.logcat.txt and let it continue running.
Install the .apk on my Android device and launch it.
Restart the application after the call to FirebaseFirestore.Collection is complete.

Per line 557 of capture.logcat.txt.

Exit logcat with Ctrl + C after application crash.

Per line 1455 of capture.logcat.txt.

capture.logcat.txt: https://gist.github.com/baba-s/e22368eb79c182457e999ffafc8b6a87
Screen recording is also attached.
https://github.com/firebase/firebase-unity-sdk/assets/6134875/d7a2f489-c8cb-4bea-87f6-ce2e42fd51a4

@baba-s Thank you for the logs and screen recording!
I have a couple of questions:

Did your application call FirebaseFirestore.LogLevel = LogLevel.Debug? If not, could you re-capture the logcat with debug logging enabled? I ask because I'm not seeing the logs that I expected to see from Firestore in the logcat. There is no need to recapture the screen recording.
Are you comfortable providing me with the app you use to reproduce the crash? If so, I could try and reproduce it for myself, which would expedite any investigation.

Thank you.

Actually, I see the debug logs. Please ignore my question #1 from the previous comment.

After doing some searching, my hypothesis that the sqlite database is still opened by the old linux process is plausible (Googlers see yaqs/210491605533065216). Apparently, Android's "ActivityManager" can incorrectly think that the linux process for a service/activity is dead (when in fact it is not yet dead) and launch a new linux process to host the service/activity. If the old process has the sqlite database opened and the new process attempts to open it then the "SQLiteDatabaseLockedException: database is locked (code 5 SQLITE_BUSY)" exception could occur. The only fix that I can think of is to add some retries if SQLiteDatabaseLockedException occurs. I'll discuss with the team.

Are you comfortable providing me with the app you use to reproduce the crash?

Hi, I have sent the .apk to your email.
The title of the email is "[GitHub Issue] .apk to reproduce Firestore crashes. 🙇

my hypothesis that the sqlite database is still opened by the old linux process is plausible

I was thinking the same thing as you.
However, the cause may possibly be different, as the crash occurs even after rebooting the Android device. 🤔

If Android device is rebooted: crash
If .apk was overwritten and installed: no crash on first boot

I suspect that the crash occurs at the point where localStore.start() is called in the initialize method of the ComponentProvider class.
https://github.com/firebase/firebase-android-sdk/blob/master/firebase-firestore/src/main/java/com/google/firebase/firestore/core/ComponentProvider.java#L156

authors: baba-s dconeybe

repo: firebase/firebase-unity-sdk


text:
[DOCS] for sample: taskqueues-backup-images, it simply doesn't work with tasks_fn.on_task_dispatched function, only  with http_fn.on_request function

Which sample?
Sample name or URL [Link to closest heading](https://firebase.google.com/docs/functions/task-functions?hl=en-us)
What is the issue with this sample's docs?
Following the code example pretty straightforward but changing the on_task_dispatched functions to simply return a "Hello world"
gives a "The request was not authorized to invoke this service" 401 error when invoking a tasks functions from a task queue.
I absolutely attempted granting all imaginable roles (cloud functions invoker, cloud run invoker, etc etc) to every service account, I tried setting oidcToken with and without the "aud" key, and setting the audience with the task functions url and and project id (because for some reason it gives an error saying it was expecting the project id in the audience key, despite every single documentation saying the you should use the functions url).
Even when calling it directly from the cloud shell, it gives an error saying "Callable request verification failed: $[('Auth token was rejected.', {'app': 'MISSING', 'auth': 'INVALID', 'logging.googleapis.com/labels': {'firebase-log-type': 'callable-request-verification'}})]"
The only thing that made it work whas change the functions to an http_fn;on_request functions, but then I won't be able to set any rety or rate limit configuration, which is kind of one of the major benefits of using a task queue.
Seriously, what am I (or the docs) doing wrong?

I'm also having trouble getting the on_task_dispatched to work. I've been using the same service account key and adding a bunch of roles. I keep seeing 401 or 403 errors in the logs and also errors with the oidc token:

Auth token was rejected.', {'app': 'MISSING', 'auth': 'INVALID', 'logging.googleapis.com/labels': {'firebase-log-type': 'callable-request-verification'}}

Error validating token: Firebase ID token has incorrect "iss" (issuer) claim. Expected "https://securetoken.google.com/" but got "https://accounts.google.com".

Error validating token: Firebase ID token has incorrect "aud" (audience) claim. Expected "" but got "https://-xxxxxxxx-uc.a.run.app".

I'm guessing that on_task_dispatched is supposed to handle all this behind the scenes, but it's not clear what i'm supposed to do. I might also give up on the on_task_dispatched and use on_request.

I got it working using the default credentials. I believe the default credentials are coming from the same service account (auto-created by Firebase) that runs these gen 2 cloud functions. For me, this service account has a principal of something like: 0000000000000-compute@developer.gserviceaccount.com
I notice that one of the roles attached to this service account is "Editor" which gives it all the Cloud Tasks permission (and much more). Maybe that's the reason why I didn't need to add any IAM roles? I also had to use SupportedRegion.US_CENTRAL1.value ("us-central1") instead of SupportedRegion.US_CENTRAL1, which becomes something like "supportedregion.us_central1" when converted to a string.
`@tasks_fn.on_task_dispatched(retry_config=options.RetryConfig(max_attempts=5, min_backoff_seconds=10),
rate_limits=options.RateLimits(max_concurrent_dispatches=10))
def populateReportTableCell(req: tasks_fn.CallableRequest) -> str:
"""Populates a cell in the report table."""
print("inside populateReportTableCell")
return "Hello from populateReportTableCell!"
@https_fn.on_call(memory=options.MemoryOption.MB_512)
def enqueue_report_gen_tasks(req: https_fn.CallableRequest):
"""Adds tasks to a Cloud Tasks queue."""
tasks_client = tasks_v2.CloudTasksClient()
task_queue = tasks_client.queue_path("myprojectid",
options.SupportedRegion.US_CENTRAL1.value,
"populateReportTableCell")
target_uri = get_function_url("populateReportTableCell")
body = {"data": "test_data"}

http_request = tasks_v2.HttpRequest(
    http_method=tasks_v2.HttpMethod.POST,
    url=target_uri,
    headers= {
        "Content-type": "application/json"
        },
    body=json.dumps(body).encode()
)
task = tasks_v2.Task(http_request=http_request)
tasks_client.create_task(parent=task_queue, task=task)

return "Hello from enqueue_report_gen_tasks!"`

I couldn't get this to work with another (non-default) service account because I kept getting "token" errors like in my previous comment. Maybe that would involve setting the service_account option in on_task_dispatched and on_call?...

Another thing, if you get this error:

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header.

you need to select "Allow unauthenticated invocations" in the GCP console in Cloud Run -> your cloud function -> Security tab -> Authentication.

If you are using python and following the docs/snippets there is a major error on them
https://github.com/firebase/functions-samples/blob/cd8938b1a7f688b236e9ad02964e140bc61e73a3/Python/taskqueues-backup-images/functions/main.py#L129
You need to use the value of the enum instead of passing the enum itself, otherwise the URL to create the task and find the function is wrong!
So instead of SupportedRegion.US_CENTRAL1 use SupportedRegion.US_CENTRAL1.value

Does anyone have a working sample using a service account? Sure, we can turn off the auth. But that's probably not good practice.

source: gharchive/issue

authors: cookbookcoding marcelpinto millerg6711 vitoras

repo: firebase/functions-samples

license_type: permissive

license_source: github-api


text:
[[STREAMS/TV]]Napoli Inter In DIRETTA Streaming gratis TV Serie A 10 novembre 2024

Inter-Napoli In DIRETTA Gratis tv e in Inter-Napoli gratis
[[STREAMS/TV]]Napoli Inter In DIRETTA Streaming gratis TV Serie A 10 novembre 2024
Oggi, sabato 10 novembre, l'Allianz Stadium di Napoli sarà il teatro della sfida tra Inter e Napoli, valida per la 12esima giornata di campionato. La partita promette scintille, con i bianconeri reduci da un pareggio in Champions League contro il Lilla. Ma cosa fare se ti trovi all'estero e vuoi seguire il match in diretta su DAZN con telecronaca in italiano? Ecco una guida completa su come vedere Inter-Napoli in Inter-Napoli ovunque tu sia, grazie a NordVPN.
La partita tra Inter e Napoli si disputerà sabato 10 novembre alle ore 20:45 all'Allianz Stadium. Il derby sarà trasmesso in Inter-Napoli su DAZN, piattaforma che detiene i diritti di co-esclusiva dell'evento. Per accedere alla diretta è necessario avere un abbonamento DAZN: la partita fa parte del pacchetto Goal Pass, disponibile a 13,99 euro al mese. La telecronaca sarà affidata a Edoardo Testoni, con il commento tecnico di Massimo Ambrosini.
I due allenatori, Thiago Motta per la Inter e Vanoli per il Napoli, hanno dovuto fare i conti con diversi infortuni. Secondo i pronostici, la Inter parte favorita grazie al fattore campo e alla posizione in classifica, ma il derby della Mole è sempre imprevedibile e il Napoli potrebbe riservare qualche sorpresa.
Se sei un tifoso bianconero o granata e ti trovi all'estero durante il match, potresti avere difficoltà a seguire la diretta Inter-Napoli a causa delle limitazioni geografiche imposte dalle piattaforme. Tuttavia, esiste una soluzione semplice ed efficace: utilizzare una VPN come NordVPN per accedere a DAZN dall'estero e goderti la telecronaca in italiano.thesdd,

dfggr

authors: daeypaover johanZones

repo: firebase/quickstart-android


text:
NFL Reddit Streams!! nfl week 10 live streams Live Streams Free ON TV Channel 12 NOV 2024

🔴Here🏈: NFL Streams
🔴Visit🏈: NFL Football 2024 Live Free

Watch NFL games for free on NFLBite, the trusted home for NFL streams since 2014. Enjoy every game, from preseason to Super Bowl, with weekly RedZone ...
🔴Here🏈: NFL Streams
🔴Visit🏈: NFL Football 2024 Live Free
NFL streams is the official backup for Reddit NFL streams. Watch every NFL games free online in your mobile, pc and tablet
🔴LINK 1🏈:
🔴LINK 2🏈:
🔴Go🏈👉NFL Network
🔴Go🏈👉NFL Streams
🔴Go🏈👉NFL Streams Free
🟢Go🏈👉NFL 2024 Week 10 Live Free
🔴Go🏈👉NFL RedZone
🟥📲👉Live Games on mobile
🟥📺👉Live Games on TV
🟥💻👉Live Games on PC
Here's How To Watch NFL Streams - Reddit NFL Streams,, Do you know what would be the best way to watch NFL in my case? Where and how is Way to Watch The NFL streams FRee, Hey fellow NFL viewers. I am a new NFL fan and with no NFL Football 2024 TV available looking for a good option to watch games here in the land down under. Here's How Can i find NFL free streams options I've been wanting to watch more games lately, but most online links I've found either skip frequently or are lower quality.
But lately I have gotten really into NFL and finally i found a great way to watch NFL for free recommend.
🔴Here🏈: NFL Streams
🔴Visit🏈: NFL Football 2024 Live Free
NFLStreams has the top 1 live streams to watch NFLStreams reddit and Football Streams HD. We OFFER NFL Redzone streams as ...Here's Way To Watch NFL Football Live Streams ReddiT on Home?,, Hey fellow NFL viewers. As I’ve been watching NFL Streams Streams for quite a few seasons now, I've done some digging to access the trusty NFL Streams Streams live NFL Streams streams. I pirate everything: sports, movies, TV Channels, and even made my own plex server. But lately I have gotten really into NFL Streams Streams and have found a great way to watch NFL Streams Streams live for free...
💻Best NFL Streams for PC/MAC 1080p/720p 👇

ghdfg

authors: hmjailing syghbvfu


text:
MLVisionTextModel duplicate symbols with React Native

I'm building an app with React Native that I've already "ejected" into its own native app project for iOS. I'm interested in using the new Firebase ML Kit Vision Text Detector for recognizing text in images using the on-device model, and I'm willing to write my own NativeModule wrapper for it (since it's so new, I don't see any existing wrappers in projects like react-native-firebase).
So, I used Cocoapods to bring in the Firebase dependencies, but when I try to compile the new workspace, I get the following linker error:
duplicate symbol __ZN3fLB28FLAGS_nosymbolize_stacktraceE in:
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(examine_stack_b03c119c7358b452600b1afd20ca186c.o)
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(utilities.o)
duplicate symbol __ZN3fLB26FLAGS_symbolize_stacktraceE in:
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(examine_stack_b03c119c7358b452600b1afd20ca186c.o)
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(utilities.o)
duplicate symbol __ZN3fLB18FLAGS_nolog_prefixE in:
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(logging_2072041cb58f7b92d4eb8dae33e75a0d.o)
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(logging.o)
duplicate symbol __ZN3fLB16FLAGS_log_prefixE in:
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(logging_2072041cb58f7b92d4eb8dae33e75a0d.o)
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(logging.o)
duplicate symbol __ZN3fLI9FLAGS_novE in:
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(vlog_is_on.o)
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(vlog_is_on_ec23571a5409c45b7e2ca681c18af4cb.o)
duplicate symbol __ZN3fLI7FLAGS_vE in:
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(vlog_is_on.o)
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(vlog_is_on_ec23571a5409c45b7e2ca681c18af4cb.o)
duplicate symbol __ZN3fLS13FLAGS_vmoduleE in:
    /Users/zainsajjad/Library/Developer/Xcode/DerivedData/peekaboosdk-hfkgohktkkwcwocawuqzpgjzslrk/Build/Products/Debug-iphonesimulator/libReact.a(vlog_is_on.o)
    /Users/zainsajjad/Desktop/development/ios/Pods/GoogleMobileVision/TextDetector/Frameworks/TextDetector.framework/TextDetector(vlog_is_on_ec23571a5409c45b7e2ca681c18af4cb.o)
ld: 7 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This issue appears when I add 'Firebase/MLVisionTextModel' in podspecs.
In case I don't add this as a dependency, it returns an empty array on the images having a good amount of text!

By podspec do you mean Podfile? Can you share your Podfile? TextDetector is a static dependency and it looks like it's being linked twice into your project.

Update: it looks like GMV and React Native have a shared c++ dependency that's causing these symbol collisions. It's unlikely that there are good workarounds for this on your end, so you'll probably have to wait for a Firebase (or RN) fix.
I'll keep this issue updated.

I am trying to publish a wrapper for MLKit Vision for React Native. Here is the podspec.
I also tried
  s.dependency     'Firebase/Core'
  s.dependency     'Firebase/MLVision'
  s.dependency     'Firebase/MLVisionTextModel'

My Project's Podfile looks like this:
platform :ios, '11.3'

target 'myApp' do
  rn_path = '../node_modules/react-native'
  rn_maps_path = '../node_modules/react-native-maps'

  # See http://facebook.github.io/react-native/docs/integration-with-existing-apps.html#configuring-cocoapods-dependencies
  pod 'yoga', path: "#{rn_path}/ReactCommon/yoga/yoga.podspec"
  pod 'React', path: rn_path, subspecs: [
    'Core',
    'CxxBridge',
    'DevSupport',
    'RCTActionSheet',
    'RCTAnimation',
    'RCTGeolocation',
    'RCTImage',
    'RCTLinkingIOS',
    'RCTNetwork',
    'RCTSettings',
    'RCTText',
    'RCTVibration',
    'RCTWebSocket',
  ]

  pod 'RNTextDetector', path: '../node_modules/react-native-text-detector/ios'
  pod 'react-native-camera', path: '../node_modules/react-native-camera'
  pod 'lottie-ios', :path => '../node_modules/lottie-ios'
  pod 'lottie-react-native', :path => '../node_modules/lottie-react-native'
  pod 'react-native-maps', path: rn_maps_path
  pod 'react-native-google-maps', path: rn_maps_path

  # React Native third party dependencies podspecs
  pod 'DoubleConversion', :podspec => "#{rn_path}/third-party-podspecs/DoubleConversion.podspec"
  pod 'glog', :podspec => "#{rn_path}/third-party-podspecs/glog.podspec"
  pod 'Folly', :podspec => "#{rn_path}/third-party-podspecs/Folly.podspec"

  # react-native-maps dependencies
  pod 'GoogleMaps'
  pod 'Google-Maps-iOS-Utils'
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == 'react-native-google-maps'
      target.build_configurations.each do |config|
        config.build_settings['CLANG_ENABLE_MODULES'] = 'No'
      end
    end
    if target.name == "React"
      target.remove_from_project
    end
  end
end

Sorry any news on problem?
I have the same problem with nativa app ios in swift.
Any idea?

@rmusetti81 you should not be running into this issue when developing a native app in Swift. Please open a new issue with all of your build information (Podfile, Podfile.lock, CocoaPods version, Xcode version).

Hi @zsajjad !  I had the exact same issue using react native and I solved enabling the dead code stripping in xcode for debug. You can enable it in Target > Build Settings > search for "Dead code stripping". For now seems to work fine.

I made my own package that uses firebase ml vision on android and CoreML+TesseractOCR on ios!

@joan-domingo's solution works fine.
For people looking here, you can use react-native-text-detector firebase branch as a wrapper around firebase ML Kit Vision.

repo: firebase/quickstart-ios

license_source: bigquery


text:
Update changelog for 0.15.1 release

Signed-off-by: Noah Meyerhans nmeyerha@amazon.com
Description of changes:
As discussed in firecracker-microvm/firectl#24, the SDK did not include a wrapper for the SendCtrlAltDel Firecracker API with the 0.15.0 release. We've since added support for that API in #81 as the machine.Shutdown() method and should release a 0.15.1 version of the SDK including this change.
This PR prepares for that release by updating the changelog.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I think you're missing an update to the version.go file.

source: gharchive/pull-request

authors: nmeyerhans samuelkarp

repo: firecracker-microvm/firecracker-go-sdk


text:
capa rule > mbc does not exactly conform to https://github.com/MBCProject/mbc-markdown!

i had to spend time to go through the output, to clean up the following mismatches/inconsistencies 😡

Anti-Behavioral Analysis::Detect Debugger => Anti-Behavioral Analysis::Debugger Detection
Anti-Behavioral Analysis::Virtual Machine Detection::Unique Hardware/Firmware Check

2 cases i found for this, depending on rule name
if rule name == "reference the VMWare IO port", then mbc = "Anti-Behavioral Analysis::Virtual Machine Detection::Unique Hardware/Firmware Check - I/O Communication Port [B0009.025]"
if rule name == "reference processor manufacturer constants", then mbc = "Anti-Behavioral Analysis::Virtual Machine Detection::Instruction Testing - CPUID [B0009.034]" (! it's not even the same subcategory !)

Anti-Static Analysis::Software Packing::Confuser [F0001.012] => Anti-Static Analysis::Software Packing::Confuser [F0001.009]
Data::Encoding::Base64 [C0026.001] => Data::Encode Data::Base64 [C0026.001]

Data::Encoding::XOR [C0026.002] => Data::Encode Data::XOR [C0026.002]
similarly, ...Decoding... => ...Decode Data...

Discovery::Analysis Tool Discovery::Process Detection [B0013.001] => Discovery::Analysis Tool Discovery::Process detection [B0013.001]
File System::Write File [C0052] => File System::Writes File [C0052]
Impact::Modify Hardware::CDROM [C0042.001] => Impact::Modify Hardware::CDROM [B0042.001]

additionally, is it too much to ask for/is there a reason for writing the a single-element: a string wrapped in an array/a list in the output, instead of structuring it, like the rest of the JSON output e.g. {"ID":"B0001.008","tactic":"Anti-Behavioral Analysis","technique":"Debugger Detection","subtechnique":"IsDebuggerPresent"}, following https://raw.githubusercontent.com/MBCProject/mbc-markdown/master/yfaq/mbc_matrix_with_ids.svg

thanks for reporting these inconsistencies @evandrix! do you want to take a stab at a PR or shall i assign myself?

is there a reason for writing the [technique as] a single-element

in the rule yaml we use the single string because we believe it is most easy for a human to read while still being concise (i understand this might be debatable, but it is simply how we do things). parsing the string for the json output is a good idea - it reduces the number of times that programmatic users of capa have to write one-off parsers for the MBC information.

Discovery::Analysis Tool Discovery::Process detection [B0013.001]

this looks like a typo in MBC

similarly, ...Decoding... => ...Decode Data...

i didn't see any of these:

authors: evandrix williballenthin

repo: fireeye/capa-rules


text:
Ftproot check

By testing FakeNet-NG as configured on REMnux, I discovered that FTPListener.py omits a helpful check that HTTPListener.py does to ensure that the defaultFiles path can be found relative to the script file itself if an absolute path is not provided. I've copied this check from the HTTP listener and tested on Remnux. @iphelix do you want to look this over and let me know if you see any problems before merging?

FTPListener now checks for rel/abs service root path the way HTTPListener does.

repo: fireeye/flare-fakenet-ng


text:
bug: low peer count within Docker vs. normal run

The Docker networking somehow causes peer discovery to be affected, although messaging works fine the peer count is very low.

When network_mode: "host" is not used, the peer count is really good within Docker
e.g. 17 peers with 15mins using host network, and 96 peers in a minute without it

https://huzaima.io/blog/connect-localhost-docker

tried all methods on ubuntu, cant get it to work for the local Ollama service (not Docker)
right now the easiest solution I can think of is to take an env variable that decides network mode, which is host on linux and bridge on others

No longer an issue with v0.2 as we use cross-platform builds instead of Docker

repo: firstbatchxyz/dkn-compute-node


text:
dbt run fails if there are external BigQuery tables in same dataset

Besides views and tables, BigQuery also supports tables of external type. When dbt materializes a model of a dataset (schema) that has external tables, it fails with
Invalid arguments passed to "BigQueryRelation" instance: property "type", 'external' is not one of ['table', 'view', 'cte', None]

Steps to reproduce

In a BigQuery project, create an external table foo.external_table (for example, use "Google Drive" as location and "Google Sheets" as file format).
Create a dbt project for this BigQuery project. Use foo as default schema.
Add a model models/foo/dbt_table.sql with any query, say SELECT 1 as bar.
Run

dbt run --models foo.dbt_table

Log message
Found 0 analyses, 56 macros, 0 tests, 55 models, 0 operations, 0 seed files, 0 archives

16:16:20 | Concurrency: 8 threads (target='development')
16:16:20 |
16:16:20 | 1 of 1 START table model foo.dbt_table............................... [RUN]
16:16:21 | 1 of 1 ERROR creating table model foo.dbt_table...................... [ERROR in 0.72s]
16:16:21 |
16:16:21 | Finished running 1 table models in 2.06s.

Completed with 1 errors:

Runtime Error in model dbt_table (models/foo/dbt_table.sql)
  Invalid arguments passed to "BigQueryRelation" instance: property "type", 'external' is not one of ['table', 'view', 'cte', None]

Done. PASS=0 ERROR=1 SKIP=0 TOTAL=1

Workaround
If there are no external tables in dataset foo, this works. So, moving foo.external_table to baz.external_table resolves the issue.

Thanks @improbable-benfischer, we'll take a look

Fixed in https://github.com/fishtown-analytics/dbt/pull/828, closing

authors: drewbanin improbable-benfischer

repo: fishtown-analytics/dbt


text:
Eats up all the storage space

Problem
Every file system change I make adds a few MB to the indexed db.

200MB and I only have 30 quotes and a small list of quote ids on the file system.

Video
Here's a video (from a different session) that shows the storage-usage going up.
http://icidasset-public.s3.amazonaws.com/Kapture 2020-08-04 at 21.53.05.mp4
Relevant code
https://github.com/icidasset/quotes/blob/6cd2d1ee5058548eae744bfb0bcc3c8a9c2716ed/src/Main.js#L49

Fixed with file system refactor.

repo: fission-suite/ts-sdk


text:
Document and/or change default behavior on uwazi-docker bind to :3000 for more than just localhost (e.g be public accessibly)

Refs: #31, #32, #33, and also https://github.com/huridocs/uwazi/issues/2047 and https://github.com/huridocs/uwazi/pull/2051

This issue is for discuss about how to document about the default behavior or even change the default behavior of uwazi-docker do expose for external access if the user does not make any changes on a default docker installation.
Even if the uwazi application change some of it's behavior, we would still need to make changes here on the docker version. Also, since we are using the v1.3 oficial release (and no really essential change must be made to affect uwazi-docker) we would still stick with the v1.3 version from 14 days ago or maybe do a very specific file patch. So it would make easier to use uwazi-docker with some more stable version than just some lastest version on uwazi development branch.

About @vasyugan comment here https://github.com/fititnt/uwazi-docker/issues/31#issuecomment-433141233

127.0.0.1:3000:3000

the official documentation says that it should work (see https://docs.docker.com/compose/compose-file/#ports, and several places on the internet, but some says like this one https://stackoverflow.com/questions/45109398/how-can-i-make-docker-compose-bind-the-containers-only-on-defined-network-instea/45133531#45133531 that it does not seems to work on docker-compose files, just on docker run). So maybe this issue is more about docker-compose version on the machine or the operational system.
I did not tested yet on my local machine (but soon will do it eventually) but even if it work or not, still a good idea discover why is not running on the Vasyugan machine. This issue can take a few days if necessary, maybe even ask other people to test after do a simple PR to merge the single like with bind to 127.0.0.1, so then can simple follow the instructions on readme and report if worked or not.

Actual version, with - 3000:3000:
# fititnt at bravo in /alligo/code/fititnt/uwazi-docker on git:master x [7:31:14]
$ docker-compose up -d uwazi
uwazi-docker_elasticsearch_1 is up-to-date
uwazi-docker_mongo_1 is up-to-date
Recreating uwazi-docker_uwazi_1 ... done

# fititnt at bravo in /alligo/code/fititnt/uwazi-docker on git:master o [7:31:42]
$ sudo netstat -ntulp | grep 3000
tcp6       0      0 :::3000                 :::*                    OUÇA       9320/docker-proxy

After replacing  - 3000:3000 with - "127.0.0.1:3000:3000"
# fititnt at bravo in /alligo/code/fititnt/uwazi-docker on git:master x [7:32:30]
$ sudo netstat -ntulp | grep 3000
tcp        0      0 127.0.0.1:3000          0.0.0.0:*               OUÇA       9642/docker-proxy

I just did not do some nmap port scanning from a outside machine to be really sure if was open or not, but I guess that - "127.0.0.1:3000:3000" should still work (the 127.0.0.1:3000 still opens the uwazi interface from my machine, so the bare minimum to make it work for a development (not a production state by default) would still work great by default, even without some additional documentation.
I think that if by default we make it a bit more safer for someone less experienced with docker and (for who whats to use as base for production) we can add more comments, but not on the simpler explanation on how to use it.
For me, if you @vasyugan if the change still work on your computer, you can just do a new PR, with no extra comments need on the docker-compose.yml for now. But we can still leave this issue open some extra time just to be sure.

@fititnt Thanks for testing! So for you, does prepending 127.0.0.1: to 3000:3000 have the effect it should have according to the docker-compose documentation or not? Because for me, it just doesn't work. The machine continues to listen on port 3000 on all network interfaces.

@vasyugan for me it works.

Closing old issues. If anyone have questions, please comment in the future!

authors: fititnt vasyugan

repo: fititnt/uwazi-docker

license: Unlicense


text:
Support "Inconclusive" as a test-result

From #55, it would be useful to support a test-result of Inconclusive. I envision this being returned if the act of running the test threw an exception or returned an error, as opposed to the test itself.
For example

if the test is trying to hit a web-service and that times out - that's a fail
if the test is trying to hit a web-service and some configuration that the test relies on is missing - that's a fail
if the test-runner thread is aborted for some (unforeseen!) reason, that's an inconclusive (it's not the test's fault, it's the runner)

My implementation of the ICheckADependency I mentioned in #55 has this as an abstract base class:
    public abstract class DependencyChecker : ICheckADependency
    {
        public string Name { get; protected set; }

        public DependencyHealthCheckResponse Execute(DependencyHealthCheck request)
        {
            try
            {
                var isHealthy = IsHealthy();
                return isHealthy
                    ? DependencyHealthCheckResponse.Up(Name)
                    : Down;
            }
            catch (Exception ex)
            {
                return new DependencyHealthCheckResponse
                {
                    Name = Name,
                    Result = new Result<DependencyHealthCheckResults>(DependencyHealthCheckResults.ErrorPreventedConclusiveCheckResult, ex.Message),
                    Message = ex.Message,
                    Raw = ex.StackTrace
                };
            }
        }

        protected DependencyHealthCheckResponse Down { private get; set; }

        protected abstract bool IsHealthy();
    }

I am creating a small specification framework on top of fixie (mostly a opinionated convention and some helper classes) and have run into the same situation (BDD, outside in testing etc.).
Is there a reason no one picked up this issue? I might want to give it a try.

@Martin-Bohring Sorry for my late reply.  Somehow I didn't get a notification.
There's no reason this hasn't been picked up yet.  It simply hasn't been a high enough priority for folks yet.
If you do, consider whether you want to start against master, which is stable and represents the 1.x releases, or dev, which is quite unstable work towards 2.x.
You'll probably be better off working against master aka 1.x, and let me worry about bringing it into 2.x once the dust settles there.

@plioi  Sound like a plan.
I stilll need to come up with a good design idea.

One idea could be to enhance  SkipBehavior and SkipResult with a typed SkipReason.
But that does not feel very SOLID to me (The Skip machinery now addressing 2 concerns)

Another idea is to introduce an InconclusiveBehaviour and an InconclusiveResult.
That sounds much better to me, but might get a bit out of control in the long run as well
(More and more behaviours introduced over time)

Another issue is since Fixie is so nicely convention based, I would like not to introduce an attribute for inconclusive tests. Maybe having an empty test case implementation could be an indicator for inconclusive tests? Or an Inconclusive convention, that is registered within a Fixie Convention?
What do you think?
Do you have a topic branch naming scheme?
I don't know when I will get to (still struggling with a sample project for another project that is simple enough for everybody to understand, but still complex enough to demonstrate advantages)
But I plan to pick it up within the next 3 weeks.

You're right to avoid wanting to add an attribute for this. We let the end users define that sort of thing themselves, and instead offer up the more general concept for them to manipulate.
I don't really think it would be a bool by the time we're done, but at least start by picturing this as a new bool property living on Case.  A convention could then set it to true if they want the failure to be suppressed. That's at least a step in the right direction.
You'll find a CaseStatus enum as well, which would probably deserve a new Inconclusive value.  I recommend that before you get into coding, follow the existing flow of these CaseStatus values through the system, to see what all would be affected by a new one.

Also, it could help to get familiar with the "Expected Exception" part of the sample NUnit convention: https://github.com/fixie/fixie/blob/master/src/Fixie.Samples/NUnitStyle/CustomConvention.cs#L80
See how this manipulates a failing case so that it starts to pass.  And end user would want to accomplish Inconslusive state very similar to this, once the feature was supported.

@plioi
I just forked the repository and found an already existing brach named InconclusiveTests
(unfortunately I don't know how to refer to branches in github flavoured markdown).
Some of the steps you have mentioned are already done on that branch. It is some 20 commits behind the master branch.
Does it make sense to continue on that branch, or is a fresh start from master the better option?

It's worth looking at it to see what my train of thought had been, but I imagine a lot has happened in master since then and it may be a dead end.  Feel free to use it as a guide, but I don't object to you starting a new branch against the latest master.

@plioi
I started to work on the issue (I wish I could invest more time than I can right now)
Are you interested in a WIP PR with a check list of what I plan to do?
That would also force me to clear my thoughts :smile:
Curremtly I am in a very early stage. I extendend the CaseStatus enumeration and propagated it through the *Result classes (As you already have done on your branch)
I recognized there are no dedicated tests for the *Result classes.
Is this by intention? I guess those are tested with the other tests anyway.
But unitl the loop is closed completely, it might still be helpful to have some tests in this area.
What do you think?

Please feel free to open a WIP PR, as long as you remind me in the description that it's a work in progress.
I have a few heavy duty tasks on my plate in the short term, so I might not have much feedback early on.
The main way that the *Result types get tested is in the tests of the various *Listener classes themselves.  The more experimental 'dev' branch is much better about that, though.

Hello @plioi , I am looking to upgrade LightBDD.Fixie integration to support fixie 3.x  but it I have realised that I no longer can mark test cases ignored/skipped if they have been executed.
I have went through the https://github.com/fixie/fixie/wiki/Customizing-the-Test-Project-Lifecycle#recipe-skipping-tests documentation but both cases describes the scenario where actual test was never executed.
In case of LightBDD integration I need to be able to begin the execution of the test method because:

by running the test, the LightBDD can record the test execution and include the result in the report,
it is possible that test owners have implemented a part of BDD scenario but indicated that some of it's sub-steps are not implemented yet and the test execution should stop with inconclusive result at that stage.

I was able to implement such behaviour with Fixie v2 but not any more with Fixie v3.
To give more context, this is the typical LightBDD test structure for Fixie (wiki link):
public partial class Basket_feature : FeatureFixture
{
    [Scenario]
    public void No_product_in_stock()
    {
        Runner.RunScenario(
            Given_product_is_out_of_stock,
            When_customer_adds_it_to_the_basket,
            Then_the_product_addition_should_be_unsuccessful,
            Then_the_basket_should_not_contain_the_product);
    }
}

The Runner.RunScenario() needs to be executed to record the scenario or control the inner steps execution, where these inner steps may request the scenario to be ignored.
The integration problem lays in the Test.RunCore() method that has paths to Pass or Fail the test run, but there is no flow allowing to Skip test that is already executing.
If fixie would allow somehow to skip such test (via some internal control mechanism, dedicated SkipExecption or ability to override the test status after it was executed), then I would be able to migrate LightBDD.Fixie version.
I tried to use a workaround and call test.Skip() after the test.Run(), but it effected with 2 test runs being reported on Solution Test Explorer.

Hello @plioi , I am looking to upgrade LightBDD.Fixie integration to support fixie 3.x  but it I have realised that I no longer can mark test cases ignored/skipped if they have been executed.
I have went through the https://github.com/fixie/fixie/wiki/Customizing-the-Test-Project-Lifecycle#recipe-skipping-tests documentation but both cases describes the scenario where actual test was never executed.
In case of LightBDD integration I need to be able to begin the execution of the test method because:

by running the test, the LightBDD can record the test execution and include the result in the report,
it is possible that test owners have implemented a part of BDD scenario but indicated that some of it's sub-steps are not implemented yet and the test execution should stop with inconclusive result at that stage.

I was able to implement such behaviour with Fixie v2 but not any more with Fixie v3.
To give more context, this is the typical LightBDD test structure for Fixie (wiki link):
public partial class Basket_feature : FeatureFixture
{
    [Scenario]
    public void No_product_in_stock()
    {
        Runner.RunScenario(
            Given_product_is_out_of_stock,
            When_customer_adds_it_to_the_basket,
            Then_the_product_addition_should_be_unsuccessful,
            Then_the_basket_should_not_contain_the_product);
    }
}

The Runner.RunScenario() needs to be executed to record the scenario or control the inner steps execution, where these inner steps may request the scenario to be ignored.
The integration problem lays in the Test.RunCore() method that has paths to Pass or Fail the test run, but there is no flow allowing to Skip test that is already executing.
If fixie would allow somehow to skip such test (via some internal control mechanism, dedicated SkipExecption or ability to override the test status after it was executed), then I would be able to migrate LightBDD.Fixie version.
I tried to use a workaround and call test.Skip() after the test.Run(), but it effected with 2 test runs being reported on Solution Test Explorer.

Hi @Suremaker,
I do have a suggestion for something to try, but I'll start by giving some context on the full story. I think that will better explain the API and give you some sample code to start with for your solution.
In practice, Fixie v2's test class lifecycle hooks were fairly limited even for very commonly requested scenarios. It was especially painful for anyone trying to do interesting things with parameterized tests, where perfectly reasonable requests from users were impossible. This led to a pretty dramatic breaking change with v3 as you've experienced. Although I regret introducing the pain of such a breaking change, I regret v1 and v2's approach even more :). v1 and v2 were trying too hard to get in the way and provide tiny hooks to consumers, where v3 is essentially trying to get out of the way and allow consumers to write a block of plain idiomatic C# with full control.
As you're experiencing, that did come with a trade-off. The primary API calls (await test.Run()) are quite opinionated. To keep most consumers from having to do a lot of "bookkeeping" while providing a simple interface, we needed to better infer what was happening during execution, and that led to a more firm stance on what a test is and what the primary "boundary" of execution is: namely that a test is an invocation of a method, and the test is absolutely 'done' (and safely reportable) once the method invocation is done.
That's a real pain for folks who wanted to recharacterize what has happened after the fact.
I'll make an analogy with a similar feature from NUnit, and then I'll get to what you can try as a workaround since I think you'll have enough context and sample code by that point to give it a try.
A similar situation is NUnit-style [ExpectedException(...)] where the test method would be allowed to complete, and then the test framework would do more work to determine whether it really passed or really failed. Over time this approach was no longer recommended for NUnit users, since it was too easy to get a test that satisfied the attribute, even when the system under test was really throwing from a different specific line than the developer was intending to nail down. That led to things like assertions for a more narrow confirmation that a specific thing throws, rather than the whole test.
Basically, the conclusion was that it's better for the test framework to own and define what the boundary of execution is, and leave the user free to make their point within the method some other way. One can imagine a similar argument against quietly recharacterizing a failure as a skip, favoring instead rewriting the test to make the same point without relying on a specialized throw to do so. But to be clear, I recognize it is highly debatable and subjective rather than a silly statement of Right vs Wrong.
I bring up ExpectedException for a few reasons. First, it should start to sound familiar to your situation, in that we have the tension between wanting a test method's execution to be 1-1 with a test result, at least most of the time, and straying from that tends to thwart expectations. Second, it is a scenario I had in mind throughout development of v3, and having that in mind helped me to keep my "NUnit imitation" scenario working. That second point led to my inclusion of an "escape hatch" for folks who really want more control. You've found part of that API in the test.Skip() method, but understandably it's not super clear what to do to get that working the way you intended without double-reporting.
With the similar ExpectedException feature in mind, see https://github.com/fixie/fixie.integration/tree/main/src/NUnitStyle.Tests and NUnitExecution  in particular. It's... a lot. We call the raw event-reporting methods test.Pass(...), test.Fail(...), and test.Skip(...) explicitly, but note that we do not call the opinionated test-runing method test.Run(...). test.Run(...) operates under the v3 stance that "running a test" means "executing the test fully and noting strictly whether or not it threw, so that reporting is automatic". Since that wouldn't be OK for ExpectedException, the NUnit behavior is met by instead call the test method directly and leaving the consumer IExecution to make sense of any exceptions/etc. The IExecution naturally has to do a lot more exception handling and control flow, as it's taking on more of Fixie's default job, but at least it has sufficient control. await test.Method.Call(...) is what you're looking for; it performs the same async-or-not handling so that you don't have to worry about that, but does not perform the "test" style exception catching/reporting, meaning that's left for you to do.
So, in summary:

Instead of calling await test.Run(...) to "run as a test" in the strict sense of the words, try the more fundamental await test.Method.Call(...) to "just call as a method" and then handle the possible exception yourself.
Be extra careful to emit a Pass, Fail, or Skip result according to your own desired logic. If you never call Fail, for instance, your customization would likely have a serious bug!
You might start with a copy of the NUnit example code, recognizing that "approximating a skip by checking for a specific expected exception" is quite similar in concept to NUnit's generalized ExpectedException concept. I think you'll find your solution can be a little simpler/shorter than the one you copy from, but not much shorter.

Please feel free to @ mention me into the LightBDD Issues if you have more questions, so the answers can be closer to where you are working.

Hello @plioi,
Thank you for the detailed response. I thought to keep this comment here so that other community members may leverage this knowledge as well.
The proposed solution worked for me and I am getting the proper behaviors for passed, skipped, and failed tests. Thank you!
It is also great to see it working nicely with Test Explorer and Resharper :)
I am happy with the solution and I am going to ship Fixie 3.x integration with LightBDD 3.7.0 (https://github.com/LightBDD/LightBDD/issues/292).

The minor note that I would like to make here is that there is no information on currently executing tests on Test Explorer or Resharper and they only pop up when the run is finished. I presume it may be related to the recorder.Start() call that is made in Test.Run() method and which does not seem to be exposed publicly.
It can be easily recreated if you make one of the NUnitStyle Tests take more time to execute by adding Thread.Sleep(TimeSpan.FromSeconds(3)); for example.
If you add the same delay to CustomConventions tests that does use Run() method under the hood, the test start is notified.
Exposing ability to notify test start will do the trick I presume.

authors: Martin-Bohring Suremaker petemounce plioi wojciech-kotlarski-insurwave

repo: fixie/fixie

license: mit


text:
[ClusterInfraAssessmentReport] failed to create ClusterPolicyReport: ClusterPolicyReport.wgpolicyk8s.io

Hello 👋
With the latest version of both the POLR Adapter and Trivy, we are currently getting:
2023/07/27 12:06:53 [ERROR] ClusterInfraAssessmentReport: Failed to process report node-ip-10-4-34-125.eu-central-1.compute.internal; failed to create ClusterPolicyReport: ClusterPolicyReport.wgpolicyk8s.io "trivy-infra-cpolr-node-ip-10-4-34-125.eu-central-1.compute.internal" is invalid: [metadata.ownerReferences.apiVersion: Invalid value: "": version must not be empty, metadata.ownerReferences.kind: Invalid value: "": kind must not be empty]

My current versions

Trivy POLR Adapter => 0.6.0
Trivy Operator => 0.15.1
Note sure if it's relevant, however, Kubernetes version => 1.27 on AWS EKS

A sample of my Trivy ClusterInfraAssessmentReport CRD

Click to expand
apiVersion: aquasecurity.github.io/v1alpha1
kind: ClusterInfraAssessmentReport
metadata:
  creationTimestamp: '2023-07-27T12:06:52Z'
  generation: 1
  labels:
    plugin-config-hash: 659b7b9c46
    resource-spec-hash: 767485d8b5
    trivy-operator.resource.kind: Node
    trivy-operator.resource.name: ip-10-4-34-125.eu-central-1.compute.internal
    trivy-operator.resource.namespace: ''
  managedFields:
    - apiVersion: aquasecurity.github.io/v1alpha1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:labels:
            .: {}
            f:plugin-config-hash: {}
            f:resource-spec-hash: {}
            f:trivy-operator.resource.kind: {}
            f:trivy-operator.resource.name: {}
            f:trivy-operator.resource.namespace: {}
          f:ownerReferences:
            .: {}
            k:{"uid":"0589c43a-b7e8-4416-a28c-2dcbadd49f1d"}: {}
        f:report:
          .: {}
          f:checks: {}
          f:scanner:
            .: {}
            f:name: {}
            f:vendor: {}
            f:version: {}
          f:summary:
            .: {}
            f:criticalCount: {}
            f:highCount: {}
            f:lowCount: {}
            f:mediumCount: {}
      manager: Go-http-client
      operation: Update
      time: '2023-07-27T12:06:52Z'
  name: node-ip-10-4-34-125.eu-central-1.compute.internal
  ownerReferences:
    - apiVersion: v1
      blockOwnerDeletion: false
      controller: true
      kind: Node
      name: ip-10-4-34-125.eu-central-1.compute.internal
      uid: 0589c43a-b7e8-4416-a28c-2dcbadd49f1d
  resourceVersion: '180364507'
  uid: 7d56069b-012e-45a3-9510-6ad315d9c1b1
  selfLink: >-
    /apis/aquasecurity.github.io/v1alpha1/clusterinfraassessmentreports/node-ip-10-4-34-125.eu-central-1.compute.internal
report:
  checks:
    - category: Kubernetes Security Check
      checkID: KCV0047
      description: Do not use self-signed certificates for TLS.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --peer-auto-tls argument is not set to true
    - category: Kubernetes Security Check
      checkID: KCV0089
      description: Setup TLS connection on the Kubelets.
      messages:
        - Ensure that the --tls-key-file argument are set as appropriate
      severity: CRITICAL
      success: false
      title: Ensure that the --tls-key-file argument are set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0135
      description: Use individual service account credentials for each controller.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --use-service-account-credentials argument is set to
        true
    - category: Kubernetes Security Check
      checkID: KCV0085
      description: Do not disable timeouts on streaming connections.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the --streaming-connection-idle-timeout argument is not set
        to 0
    - category: Kubernetes Security Check
      checkID: KCV0079
      description: Disable anonymous requests to the Kubelet server.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: Ensure that the --anonymous-auth argument is set to false
    - category: Kubernetes Security Check
      checkID: KCV0037
      description: >-
        Allow pods to verify the API server's serving certificate before
        establishing connections.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --root-ca-file argument is set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0042
      description: Configure TLS encryption for the etcd service.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --cert-file and --key-file arguments are set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0001
      description: Disable anonymous requests to the API server.
      messages:
        - ''
      severity: MEDIUM
      success: true
      title: Ensure that the --anonymous-auth argument is set to false
    - category: Kubernetes Security Check
      checkID: KCV0092
      description: >-
        Ensure that the Kubelet is configured to only use strong cryptographic
        ciphers.
      messages:
        - Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers
      severity: CRITICAL
      success: false
      title: Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers
    - category: Kubernetes Security Check
      checkID: KCV0087
      description: >-
        Security relevant information should be captured. The --event-qps flag
        on the Kubelet can be used to limit the rate at which events are
        gathered
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the --event-qps argument is set to 0 or a level which
        ensures appropriate event capture
    - category: Kubernetes Security Check
      checkID: KCV0033
      description: Activate garbage collector on pod termination, as appropriate.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --terminated-pod-gc-threshold argument is set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0006
      description: Verify kubelet's certificate before establishing connection.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --kubelet-certificate-authority argument is set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0019
      description: >-
        Enable auditing on the Kubernetes API Server and set the desired audit
        log path.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --audit-log-path argument is set
    - category: Kubernetes Security Check
      checkID: KCV0071
      description: >-
        If kube-proxy is running, and if it is using a file-based kubeconfig
        file, ensure that the proxy kubeconfig file has permissions of 600 or
        more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        If proxy kubeconfig file exists ensure permissions are set to 600 or
        more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0077
      description: >-
        Ensure that if the kubelet refers to a configuration file with the
        --config argument, that file has permissions of 600 or more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        If the kubelet config.yaml configuration file is being used validate
        permissions set to 600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0063
      description: Ensure that the scheduler config  file ownership is set to root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: Ensure that the scheduler config  file ownership is set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0048
      description: >-
        Ensure that the API server pod specification file has permissions of 600
        or more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the API server pod specification file permissions are set to
        600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0069
      description: >-
        Ensure that the kubelet service file has permissions of 600 or more
        restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the kubelet service file permissions are set to 600 or more
        restrictive
    - category: Kubernetes Security Check
      checkID: KCV0065
      description: >-
        Ensure that the controller-manager config  file ownership is set to
        root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the controller-manager config  file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0057
      description: >-
        Ensure that the container network interface file ownership is set to
        root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the container network interface file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0026
      description: >-
        etcd should be configured to make use of TLS encryption for client
        connections.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0007
      description: Do not always authorize all requests.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --authorization-mode argument is not set to AlwaysAllow
    - category: Kubernetes Security Check
      checkID: KCV0036
      description: >-
        Explicitly set a service account private key file for service accounts
        on the controller manager.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --service-account-private-key-file argument is set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0078
      description: >-
        Ensure that if the kubelet refers to a configuration file with the
        --config argument, that file is owned by root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        If the kubelet config.yaml configuration file is being used validate
        file ownership is set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0052
      description: >-
        Ensure that the scheduler pod specification file has permissions of 600
        or more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the scheduler pod specification file permissions are set to
        600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0013
      description: >-
        The SecurityContextDeny admission controller can be used to deny pods
        which make use of some SecurityContext fields which could allow for
        privilege escalation in the cluster. This should be used where
        PodSecurityPolicy is not in place within the cluster.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the admission control plugin SecurityContextDeny is set if
        PodSecurityPolicy is not used
    - category: Kubernetes Security Check
      checkID: KCV0003
      description: >-
        This admission controller rejects all net-new usage of the Service field
        externalIPs.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --DenyServiceExternalIPs is not set
    - category: Kubernetes Security Check
      checkID: KCV0014
      description: Automate service accounts management.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the admission control plugin ServiceAccount is set
    - category: Kubernetes Security Check
      checkID: KCV0084
      description: Allow Kubelet to manage iptables.
      messages:
        - ''
      severity: HIGH
      success: true
      title: Ensure that the --make-iptables-util-chains argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0067
      description: Ensure that the Kubernetes PKI key file permission is set to 600.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: Ensure that the Kubernetes PKI key file permission is set to 600
    - category: Kubernetes Security Check
      checkID: KCV0088
      description: Setup TLS connection on the Kubelets.
      messages:
        - Ensure that the --tls-cert-file argument are set as appropriate
      severity: CRITICAL
      success: false
      title: Ensure that the --tls-cert-file argument are set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0011
      description: Do not allow all requests.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the admission control plugin AlwaysAdmit is not set
    - category: Kubernetes Security Check
      checkID: KCV0081
      description: Enable Kubelet authentication using certificates.
      messages:
        - Ensure that the --client-ca-file argument is set as appropriate
      severity: CRITICAL
      success: false
      title: Ensure that the --client-ca-file argument is set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0004
      description: Use https for kubelet connections.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --kubelet-https argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0044
      description: Do not use self-signed certificates for TLS.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --auto-tls argument is not set to true
    - category: Kubernetes Security Check
      checkID: KCV0091
      description: Enable kubelet server certificate rotation.
      messages:
        - Verify that the RotateKubeletServerCertificate argument is set to true
      severity: HIGH
      success: false
      title: Verify that the RotateKubeletServerCertificate argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0056
      description: >-
        Ensure that the container network interface file has permissions of 600
        or more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the container network interface file permissions are set to
        600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0017
      description: Do not disable the secure port.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --secure-port argument is not set to 0
    - category: Kubernetes Security Check
      checkID: KCV0061
      description: Ensure that the admin config  file ownership is set to root:root.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: Ensure that the admin config  file ownership is set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0028
      description: Setup TLS connection on the API server.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --client-ca-file argument is set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0040
      description: Disable profiling, if not needed.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --profiling argument is set to false
    - category: Kubernetes Security Check
      checkID: KCV0002
      description: Do not use token based authentication.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --token-auth-file parameter is not set
    - category: Kubernetes Security Check
      checkID: KCV0054
      description: >-
        Ensure that the etcd pod specification file has permissions of 600 or
        more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the etcd pod specification file permissions are set to 600
        or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0070
      description: Ensure that the kubelet service file ownership is set to root:root.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: Ensure that the kubelet service file ownership is set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0021
      description: Retain 10 or an appropriate number of old log files.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --audit-log-maxbackup argument is set to 10 or as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0045
      description: >-
        etcd should be configured to make use of TLS encryption for peer
        connections.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --peer-cert-file and --peer-key-file arguments are set
        as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0015
      description: Reject creating objects in a namespace that is undergoing termination.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the admission control plugin NamespaceLifecycle is set
    - category: Kubernetes Security Check
      checkID: KCV0075
      description: >-
        Ensure that the certificate authorities file has permissions of 600 or
        more restrictive.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: >-
        Ensure that the certificate authorities file permissions are set to 600
        or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0080
      description: Do not allow all requests. Enable explicit authorization.
      messages:
        - >-
          Ensure that the --authorization-mode argument is not set to
          AlwaysAllow
      severity: HIGH
      success: false
      title: Ensure that the --authorization-mode argument is not set to AlwaysAllow
    - category: Kubernetes Security Check
      checkID: KCV0055
      description: >-
        Ensure that the etcd pod specification file ownership is set to
        root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the etcd pod specification file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0068
      description: >-
        Ensure that the Kubernetes PKI certificate file permission is set to
        600.
      messages:
        - ''
      severity: HIGH
      success: true
      title: Ensure that the Kubernetes PKI certificate file permission is set to 600
    - category: Kubernetes Security Check
      checkID: KCV0038
      description: Enable kubelet server certificate rotation on controller-manager.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the RotateKubeletServerCertificate argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0043
      description: Enable client authentication on etcd service.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --client-cert-auth argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0029
      description: >-
        etcd should be configured to make use of TLS encryption for client
        connections.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --etcd-cafile argument is set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0066
      description: >-
        Ensure that the Kubernetes PKI directory and file file ownership is set
        to root:root.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: >-
        Ensure that the Kubernetes PKI directory and file file ownership is set
        to root:root
    - category: Kubernetes Security Check
      checkID: KCV0046
      description: etcd should be configured for peer authentication.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --peer-client-cert-auth argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0008
      description: Restrict kubelet nodes to reading only objects associated with them.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --authorization-mode argument includes Node
    - category: Kubernetes Security Check
      checkID: KCV0025
      description: >-
        Explicitly set a service account public key file for service accounts on
        the apiserver.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --service-account-key-file argument is set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0027
      description: Setup TLS connection on the API server.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --tls-cert-file and --tls-private-key-file arguments are
        set as appropriate
    - category: Kubernetes Security Check
      checkID: KCV0009
      description: Turn on Role Based Access Control.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --authorization-mode argument includes RBAC
    - category: Kubernetes Security Check
      checkID: KCV0022
      description: Rotate log files on reaching 100 MB or as appropriate.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --audit-log-maxsize argument is set to 100 or as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0020
      description: Retain the logs for at least 30 days or as appropriate.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --audit-log-maxage argument is set to 30 or as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0083
      description: >-
        Protect tuned kernel parameters from overriding kubelet default kernel
        parameter values.
      messages:
        - Ensure that the --protect-kernel-defaults is set to true
      severity: HIGH
      success: false
      title: Ensure that the --protect-kernel-defaults is set to true
    - category: Kubernetes Security Check
      checkID: KCV0074
      description: Ensure that the kubelet.conf file ownership is set to root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the --kubeconfig kubelet.conf file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0082
      description: Disable the read-only port.
      messages:
        - ''
      severity: HIGH
      success: true
      title: Verify that the --read-only-port argument is set to 0
    - category: Kubernetes Security Check
      checkID: KCV0049
      description: >-
        Ensure that the API server pod specification file ownership is set to
        root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the API server pod specification file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0064
      description: >-
        Ensure that the controller-manager config file has permissions of 600 or
        more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the controller-manager config file permissions are set to
        600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0016
      description: Limit the Node and Pod objects that a kubelet could modify.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the admission control plugin NodeRestriction is set
    - category: Kubernetes Security Check
      checkID: KCV0062
      description: >-
        Ensure that the scheduler config file has permissions of 600 or more
        restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the scheduler config file permissions are set to 600 or more
        restrictive
    - category: Kubernetes Security Check
      checkID: KCV0018
      description: Disable profiling, if not needed.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --profiling argument is set to false
    - category: Kubernetes Security Check
      checkID: KCV0060
      description: >-
        Ensure that the admin config file has permissions of 600 or more
        restrictive.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: >-
        Ensure that the admin config file permissions are set to 600 or more
        restrictive
    - category: Kubernetes Security Check
      checkID: KCV0073
      description: >-
        Ensure that the kubelet.conf file has permissions of 600 or more
        restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the --kubeconfig kubelet.conf file permissions are set to
        600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0051
      description: >-
        Ensure that the controller manager pod specification file ownership is
        set to root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the controller manager pod specification file ownership is
        set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0059
      description: Ensure that the etcd data directory ownership is set to etcd:etcd.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the etcd data directory ownership is set to etcd:etcd
    - category: Kubernetes Security Check
      checkID: KCV0050
      description: >-
        Ensure that the controller manager pod specification file has
        permissions of 600 or more restrictive.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the controller manager pod specification file permissions
        are set to 600 or more restrictive
    - category: Kubernetes Security Check
      checkID: KCV0072
      description: >-
        If kube-proxy is running, ensure that the file ownership of its
        kubeconfig file is set to root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: if proxy kubeconfig file exists ensure ownership is set to root:root
    - category: Kubernetes Security Check
      checkID: KCV0039
      description: Do not bind the scheduler service to non-loopback insecure addresses.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --bind-address argument is set to 127.0.0.1
    - category: Kubernetes Security Check
      checkID: KCV0024
      description: Validate service account before validating token.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --service-account-lookup argument is set to true
    - category: Kubernetes Security Check
      checkID: KCV0010
      description: Limit the rate at which the API server accepts requests.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the admission control plugin EventRateLimit is set
    - category: Kubernetes Security Check
      checkID: KCV0086
      description: Do not override node hostnames.
      messages:
        - Ensure that the --hostname-override argument is not set
      severity: HIGH
      success: false
      title: Ensure that the --hostname-override argument is not set
    - category: Kubernetes Security Check
      checkID: KCV0030
      description: Encrypt etcd key-value store.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --encryption-provider-config argument is set as
        appropriate
    - category: Kubernetes Security Check
      checkID: KCV0058
      description: >-
        Ensure that the etcd data directory has permissions of 700 or more
        restrictive.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the etcd data directory permissions are set to 700 or more
        restrictive
    - category: Kubernetes Security Check
      checkID: KCV0090
      description: Enable kubelet client certificate rotation.
      messages:
        - Ensure that the --rotate-certificates argument is not set to false
      severity: HIGH
      success: false
      title: Ensure that the --rotate-certificates argument is not set to false
    - category: Kubernetes Security Check
      checkID: KCV0053
      description: >-
        Ensure that the scheduler pod specification file ownership is set to
        root:root.
      messages:
        - ''
      severity: HIGH
      success: true
      title: >-
        Ensure that the scheduler pod specification file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0076
      description: >-
        Ensure that the certificate authorities file ownership is set to
        root:root.
      messages:
        - ''
      severity: CRITICAL
      success: true
      title: >-
        Ensure that the client certificate authorities file ownership is set to
        root:root
    - category: Kubernetes Security Check
      checkID: KCV0034
      description: Disable profiling, if not needed.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --profiling argument is set to false
    - category: Kubernetes Security Check
      checkID: KCV0041
      description: Do not bind the scheduler service to non-loopback insecure addresses.
      messages:
        - ''
      severity: LOW
      success: true
      title: Ensure that the --bind-address argument is set to 127.0.0.1
    - category: Kubernetes Security Check
      checkID: KCV0005
      description: Enable certificate based kubelet authentication.
      messages:
        - ''
      severity: LOW
      success: true
      title: >-
        Ensure that the --kubelet-client-certificate and --kubelet-client-key
        arguments are set as appropriate
  scanner:
    name: Trivy
    vendor: Aqua Security
    version: 0.15.0
  summary:
    criticalCount: 4
    highCount: 5
    lowCount: 0
    mediumCount: 0

hey, thanks for reporting. I will have a look

awesome! Thanks a lot

@fjogeleit I also noticed something else in the logs:
2023/07/27 12:15:36 [ERROR] ClusterInfraAssessmentReport: Failed to delete report node-ip-10-4-42-36.eu-central-1.compute.internal; an empty namespace may not be set when a resource name is provided

Not sure if that's related ..

@fjogeleit I am seeing now a panic panic: runtime error: invalid memory address or nil pointer dereference .. I am on Kubernetes 1.27 .. have you already upgraded the k8s API Go Lib? (https://github.com/kubernetes/kubernetes/issues/118361#issuecomment-1579198407)

Hm can you post the panic message? Do you see some stacktraces? Will have a deeper look, sorry.

All good thanks for your prompt answer. Here you go with the whole log dump:
[INFO] start server on port 8080
[INFO] ConfigAuditReports enabled
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x14e6f8a]

goroutine 1 [running]:
github.com/fjogeleit/trivy-operator-polr-adapter/pkg/adapters/auditr.(*Client).StartWatching(0xc0002dfda0, {0x1ae16c8?, 0xc000138000})
	/app/pkg/adapters/auditr/client.go:25 +0x4a
github.com/fjogeleit/trivy-operator-polr-adapter/cmd.newRunCMD.func1(0xc0004a8300, {0x1853b41?, 0x0?, 0x0?})
	/app/cmd/run.go:73 +0x285
github.com/spf13/cobra.(*Command).execute(0xc0004a8300, {0x26c2880, 0x0, 0x0})
	/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:940 +0x862
github.com/spf13/cobra.(*Command).ExecuteC(0xc0004a8000)
	/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:1068 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
	/go/pkg/mod/github.com/spf13/cobra@v1.7.0/command.go:992
main.main()
	/app/main.go:13 +0x2c

Thanks, I fixed the logger issue and tested it local. I released a version 0.7.2. You can test it again after the build finished.

Unfortunately still the same error 😢

The panic or the APIVersion issue?

The panic I meant ..

Hm okay, will check again

No stress .. currently I rolled back to 0.6.0 where the POLR Adapter isn't panicking ..

Hm audit report was not enabled in my test. Tested now all reports and published a 0.7.3. Sorry for the issues.
[INFO] start server on port 8080
[INFO] ConfigAuditReports enabled
[INFO] VulnerabilityReports enabled
[INFO] ComplianceReports enabled
[INFO] RbacAssessmentReports enabled
[INFO] ExposedSecretReports enabled
[INFO] InfraAssessmentReportClient enabled
[INFO] ClusterInfraAssessmentReportClient enabled
I0727 18:59:10.680466   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="configaudit" "source"="kind source: *v1alpha1.ConfigAuditReport"
I0727 18:59:10.680767   27703 controller.go:185]  "msg"="Starting Controller" "controller"="configaudit"
I0727 18:59:10.680773   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="exposedsecret" "source"="kind source: *v1alpha1.ExposedSecretReport"
I0727 18:59:10.680795   27703 controller.go:185]  "msg"="Starting Controller" "controller"="exposedsecret"
I0727 18:59:10.680467   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="compliance" "source"="kind source: *v1alpha1.ClusterComplianceReport"
I0727 18:59:10.680842   27703 controller.go:185]  "msg"="Starting Controller" "controller"="compliance"
I0727 18:59:10.680484   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="vulnerability" "source"="kind source: *v1alpha1.VulnerabilityReport"
I0727 18:59:10.680887   27703 controller.go:185]  "msg"="Starting Controller" "controller"="vulnerability"
I0727 18:59:10.680492   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="clusterrbacassessment" "source"="kind source: *v1alpha1.ClusterRbacAssessmentReport"
I0727 18:59:10.680634   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="infraassessment" "source"="kind source: *v1alpha1.InfraAssessmentReport"
I0727 18:59:10.681103   27703 controller.go:185]  "msg"="Starting Controller" "controller"="infraassessment"
I0727 18:59:10.680866   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="clusterinfraassessment" "source"="kind source: *v1alpha1.ClusterInfraAssessmentReport"
I0727 18:59:10.681174   27703 controller.go:185]  "msg"="Starting Controller" "controller"="clusterinfraassessment"
I0727 18:59:10.680921   27703 controller.go:177]  "msg"="Starting EventSource" "controller"="rbacassessment" "source"="kind source: *v1alpha1.RbacAssessmentReport"
I0727 18:59:10.680970   27703 controller.go:185]  "msg"="Starting Controller" "controller"="clusterrbacassessment"
I0727 18:59:10.681313   27703 controller.go:185]  "msg"="Starting Controller" "controller"="rbacassessment"
I0727 18:59:10.818262   27703 controller.go:219]  "msg"="Starting workers" "controller"="clusterrbacassessment" "worker count"=1
I0727 18:59:10.818338   27703 controller.go:219]  "msg"="Starting workers" "controller"="vulnerability" "worker count"=1
I0727 18:59:10.818343   27703 controller.go:219]  "msg"="Starting workers" "controller"="infraassessment" "worker count"=1
I0727 18:59:10.818396   27703 controller.go:219]  "msg"="Starting workers" "controller"="clusterinfraassessment" "worker count"=1
I0727 18:59:10.818477   27703 controller.go:219]  "msg"="Starting workers" "controller"="configaudit" "worker count"=1
I0727 18:59:10.818928   27703 controller.go:219]  "msg"="Starting workers" "controller"="rbacassessment" "worker count"=1
I0727 18:59:10.819273   27703 controller.go:219]  "msg"="Starting workers" "controller"="exposedsecret" "worker count"=1
I0727 18:59:10.819403   27703 controller.go:219]  "msg"="Starting workers" "controller"="compliance" "worker count"=1

I released Helm Chart version 0.7.0 with the fixed image version 0.7.3

authors: fjogeleit sherifkayad

repo: fjogeleit/trivy-operator-polr-adapter

license: MIT


text:
Colliders collide with each other, but there are some areas that do not detect collisions.

Current bug behavior

Colliders collide with each other, but there are some areas that do not detect collisions.
Expected behavior

Steps to reproduce

Flutter doctor output

Output of: flutter doctor -v

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.8, on macOS 13.0.1 22A400 darwin-arm, locale ko-KR)
[!] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.2)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.1)
[✓] VS Code (version 1.76.1)
[✓] Connected device (4 available)
[✓] HTTP Host Availability

More environment information

flame: ^1.6.0
Platform affected: ios
Platform version affected: ios 16.2

Log information

Enter log information in this code block

More information

Obviously, it's a normal area to detect a collision, but it doesn't collide and just passes through it.

https://user-images.githubusercontent.com/41276448/225190478-bda3716a-2c38-42cb-ab22-1fbad326e22e.mov
you can check my issue
i upload video and image

Can you place a rect and a circle in that specific configuration with no movement and see if it still doesn't trigger the collision callbacks?

@ufrshubham  https://github.com/Umigishi-Aoi/block_breaker code here
i used him code

@kindkmj can you confirm that indeed the collision callbacks are not called? I'm suspecting that maybe your collisions handling code might be flawed.
Can you provide a minimal reproducible example where we wouldn't have to play the game and encounter this issue randomly?

i will try it ...

@spydon no i don`t because i think flutter flame not ready package
change my project unity

authors: kindkmj ufrshubham

repo: flame-engine/flame


text:
feat: Add HasTimeScale mixin

Description
This PR adds a new mixin on Component. When attached to a component, it allows scaling the delta time of that component as well as all its children by a non-negative factor. The idea is to allows slowing down or speeding up the gameplay by change the scaling factor.
Note: This approach works only for framerate independent game logic. Code in update() that is not dependent on delta time will remain unaffected by time scale.
Here are few examples:
https://user-images.githubusercontent.com/33748002/227756636-ee00405a-2d6a-4751-91a3-2b78a522e723.mp4
https://user-images.githubusercontent.com/33748002/227756645-bc570e6b-4985-4d51-8f1a-5f2cbaef99c6.mp4
Checklist

[x] I have followed the [Contributor Guide] when preparing my PR.
[ ] I have updated/added tests for ALL new/updated/fixed functionality.
[ ] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples or docs.

Breaking Change?

[ ] Yes, this PR is a breaking change.
[x] No, this PR is not a breaking change.

Related Issues
Closes #2392

This is the smarter implementation of the whole game timescale.  I was also working on this but @ufrshubham had a great idea to make this component specific so you can allow somethings to be changed and not others kind of like matrix bullet time and stuff.  Overall, I think it's a brilliantly simple and effective solution.

Nice! Needs some docs and tests otherwise it looks good to me. :)

Nice! Needs some docs and tests otherwise it looks good to me. :)

Cool! Just wanted a go-ahead before jumping onto tests and docs. I'll get started with that now 🙂

Lgtm, would be really nice if the example ran directly in the docs too!

Added a simple example in docs too.

authors: munsterlander spydon ufrshubham