除H5端以外，sass的api配置无效

[xiaohe0601]

trafficstars

sass 从 1.79.1 开始会提示 2.0.0 后会移除 legacy API

Deprecation Warning: The legacy JS API is deprecated and will be removed in Dart Sass 2.0.0.

通过配置 Vite 的 css.preprocessorOptions 可以修改使用的 sass API

// vite.config.ts

export default defineConfig({
  // ...
  css: {
    preprocessorOptions: {
      scss: {
        api: 'modern'
      }
    }
  }
});

配置后H5端不再出现warning，但是其他端依然会有提示

版本信息

• uniapp：3.0.0-4020420240722002
• vue：3.4.38
• sass：1.79.1

[coderabbitai[bot]]

[!IMPORTANT]

Review skipped

Auto reviews are limited to specific labels.

:label: Labels to auto review (1)

• llm-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[ellemouton]

@starius - I think these unit test failures are related to this PR - maybe take a look at fixing those up first & then re-ping reviewers when ready?

[starius]

@Crypt-iQ

I couldn't reproduce the race condition with the attached test, do you have an error trace of it?

I pushed branch reproduce-race to my fork.

In that branch:

htlcswitch$ go test -race -run TestSwitchGetAttemptResultStress
==================
WARNING: DATA RACE
Read at 0x00c0001d4118 by goroutine 21:
  runtime.raceread()
      <autogenerated>:1 +0x1e
  github.com/lightningnetwork/lnd/htlcswitch.(*Switch).GetAttemptResult()
      /home/user/lnd/htlcswitch/switch.go:496 +0x1c4
  github.com/lightningnetwork/lnd/htlcswitch.TestSwitchGetAttemptResultStress.func1()
      /home/user/lnd/htlcswitch/switch_test.go:3211 +0x168

Previous write at 0x00c0001d4118 by goroutine 22:
  runtime.racewrite()
      <autogenerated>:1 +0x1e
  github.com/lightningnetwork/lnd/htlcswitch.(*Switch).Stop()
      /home/user/lnd/htlcswitch/switch.go:1995 +0x1e9
  github.com/lightningnetwork/lnd/htlcswitch.TestSwitchGetAttemptResultStress.func2()
      /home/user/lnd/htlcswitch/switch_test.go:3232 +0xae

Goroutine 21 (running) created at:
  github.com/lightningnetwork/lnd/htlcswitch.TestSwitchGetAttemptResultStress()
      /home/user/lnd/htlcswitch/switch_test.go:3203 +0x356
  testing.tRunner()
      /home/user/.goroot/src/testing/testing.go:1690 +0x226
  testing.(*T).Run.gowrap1()
      /home/user/.goroot/src/testing/testing.go:1743 +0x44

Goroutine 22 (finished) created at:
  github.com/lightningnetwork/lnd/htlcswitch.TestSwitchGetAttemptResultStress()
      /home/user/lnd/htlcswitch/switch_test.go:3222 +0x45c
  testing.tRunner()
      /home/user/.goroot/src/testing/testing.go:1690 +0x226
  testing.(*T).Run.gowrap1()
      /home/user/.goroot/src/testing/testing.go:1743 +0x44
==================
--- FAIL: TestSwitchGetAttemptResultStress (0.08s)
    testing.go:1399: race detected during execution of test
FAIL
exit status 1
FAIL    github.com/lightningnetwork/lnd/htlcswitch      0.380s

[starius]

@starius - I think these unit test failures are related to this PR - maybe take a look at fixing those up first & then re-ping reviewers when ready?

Test failure was caused by extra call to s.Stop in defer. I removed it.

[ProofOfKeags]

What's the prio on this? I want to review but I need to balance with other stuff.

[saubyk]

What's the prio on this? I want to review but I need to balance with other stuff.

Not critical. You can focus on P0 stuff, before addressing this.

[starius]

Sorry a bit late in the game, but is there an issue page describing what the issue is?

@yyforyongyu Thank you for the suggestion! I opened https://github.com/lightningnetwork/lnd/issues/9308 to describe the original issue.

I also don't understand the struct GoroutineManager - it looks like it's putting a mutex to guard the wait group operations?

WaitGroup cannot be directly used to track goroutines in the scenario we encounter in htlcswitch. The issue arises when we have a long-lived object (the switch) that launches goroutines during its lifecycle (via the GetAttemptResult method, which calls wg.Add(1)) and a Stop() method, which cancels running goroutines (using context cancellation) and waits for them to complete (via wg.Wait()).

In this setup, wg.Add(1) and wg.Wait() can be called in parallel when the WaitGroup counter is at 0. At this point, WaitGroup cannot determine whether it should wait or not because the outcome depends on the timing and order of these calls. Essentially, this creates a situation where switch.Stop() doesn’t know whether to wait for a goroutine launched by GetAttemptResult if it was initiated at the same time Stop() was called. This results in a race condition.

GoroutineManager resolves this issue by introducing a Go method that is synchronized with the Stop method. This ensures that either a goroutine is successfully launched or the Go method returns false. This synchronization is achieved by using a mutex alongside the WaitGroup.

My instinct is this is solving the wrong problem - we should always know when/where we call wg.Add and wg.Wait, if not, we should refactor our code so we always know when we cal wg.Add and wg.Wait. I guess other people have run into this issue before too.

I agree that, ideally, the code should be refactored into an event-loop style, centralizing all goroutine launches and state changes within a single goroutine and using channels to transmit data to and from it. This approach aligns with the patterns we follow in other packages. However, implementing such a change would require significant time and extensive modifications to the package. What are your thoughts?

[starius]

I squashed the last commit (https://github.com/lightningnetwork/lnd/pull/9140/commits/deeacc62478bbe5f6b8fe1f2ee6cae02e3d7c8c1), rebased and used GoroutineManager from fn v2. Fortunately fn v1 and fn v2 can be used simultaneously!

[ellemouton]

@starius - those 2 PRs are in now so I think we can continue here

[starius]

Squashed the commits.

[starius]

@yyforyongyu

The other approach is simply removing the wg.Add - why do we need it or am I missing anything here?

If we remove wg.Add, we would end up with an untracked goroutine. The purpose of the WaitGroup here is to ensure that all started goroutines are properly accounted for and to wait for their completion in Switch.Stop(). This guarantees that all goroutines have finished before the switch is turned off.

[yyforyongyu]

I don't think my comments are addressed. I've provided two alternatives that we don't need the wg.Add, plus this question,

Or my question is this - now that we have the new fn.GoroutineManager, how are we gonna prevent future development from using it to cover the mistake that a wg.Add is called inside a goroutine?

[lightninglabs-deploy]

@yyforyongyu: review reminder @starius, remember to re-request review from reviewers when ready

[yyforyongyu]

!lightninglabs-deploy mute